Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Extensions slower than mods?

edited March 2007 in Vanilla 1.0 Help
Looking at how extensions are implemented, I'm wondering if extensions are slower than mods. Mods are hacks for forums like vB or IPB where you have to manually edit core codes. I like how extensions are in their own files and you don't have to touch the core code, but is it slower to do so?
«1

Comments

  • I wondered that too, but I think the answer is "No". You can tuck away most or all of an extension's code inside of an if() block so that it only loads specifically when you need it. Evaluating an if() condition takes practically no time at all and, as you noticed, it keeps the Vanilla code clean so I'd say it's worth it.
  • Yes, that is a good point but when you have a A LOT of extensions, those if blocks start to add up. All the code within the defaults is included within every page, right? So if you have a lot of extensions, that one page can have a lot of if blocks.
  • the answer is yes,

    extensions slowing the baby down.

    but this is not an exclusive problem of vanilla, its the nature of extensions or plugins (apps in a app).

    modifications are better if you want to keep a better performance.

    but at least there are a few mini extensions with not much code inside and without any css , ajax or .js fun, so they should be fine.
  • Hm, I see. Then assuming all the extensions I will install are fairly large, how many of them can I install before I will notice it slowing down?
  • the extensions here are not classified, so you have to find it out somehow.

    sry
  • Max_BMax_B New
    edited February 2007
    And some extensions add more overhead, when they need to access database. Sometime there is no appropriate delegate to allow adding to an already building request so the extension writer must add a separate request.Which is bad.
    I know, I had to do it…
    That's the price to pay.
  • To be honest, based on Vanilla itself being considerably quicker than vB or IPB anyway, the fact that extensions are seperated rather than hacked into the code mean the end result is probably still quicker, depending on what extensions you have running. With object orientated code and delegation in place anyway I really dont think performance hits due to the extension method (note: not due to particularly 'heavy' extensions) should be anything to worry about.
  • MarkMark Vanilla Staff
    It really depends on the extension. Extensions that access the db are going to be slower, for sure. But as was mentioned above, no matter how big an extension is, it should be encased in an if statement and ignored if not needed - and it takes almost no time to skip over the code.
  • Ok, thanks. :) How much slower will the extension be, assuming worst case?
  • days...
  • edited March 2007
    Let me clarify: Worst case = an extension which heavily uses a database, but also assuming that their code is decently programmed.
  • A well-behaved extension should be not noticeably slower than a mod in any case.
  • @squirrel: sorry but no. There are some task which cannot be done as efficiently from an extension.

    I'm not arguing against extension paradigm. It's the right design. But there is a drawback and admin must be aware of it and incrementally test their install against extensions, depending of the forum usage.
  • hey guys, integration is allways faster as a seperated addition. its a general rule of physic.

    vanilla is cool, extensions are cool (for me as admin), but there is no reason to make more out of it as it is.

    before i switched to vanilla it was the same: fery , everything is possible, you can do this and that, you are able to create pink elefants with vanillas framework, "not possible doesnt exist for vanilla".

    and the result was something else.

    please dont fool new members with personal theories and fancy promises, this is somehow unfair and unproductive.

    as mark allready said (a few months back), vanilla is not the fastest board on the market (just use search)
  • edited March 2007
    Vanilla is a plain forum engine, it is aim to be easy to customize. The only part that is difficult to change is the part that is created before the extensions are loaded (e.g. the multi-language extension of Max_B need a patch). Adding feature with "$Context->ObjectFactory->SetReference("MyNeatClass", "AnotherClass");" (http://lussumo.com/docs/doku.php?id=vanilla:development:objectfactory#setting_up_class_references) doesn't slow down vanilla at all. That's just not very good for public addons, but that's good for modification that doesn't need to be share. Delegations allow to add code to a class. Adding it with a delegation instead of a patch to a class has a negligible impact on performance. Nobody claimed vanilla is the fastest forum application. Nobody claimed vanilla is the one forum solution, that is a perfect solution for everybody. Vanilla is the middle solution between trying to modified something like phpBB and build your forum from scratch.
  • To be honest, the only things you need to ask is this - is it fast enough for you? If it is, great, if not, keep looking :) (Or ask mark to make it quicker)
  • I'd love to have debugging tools to 'profile/time' add-ons, so I can make a 'delay vs functionality'
    or 'hack vs extend' decision. I really miss those tools. I'd love me some query timer totals, all
    seconds spent on SQL vs page generation, etc. etc.
  • Firebug (and various other browser tools) will tell you exactly how long each element of the page is taking to load - it wont tell you how long the SQL queries took but really unless you're ready to go digging through optomising them then that information isnt all too useful. Time how long an extension adds to the page load (with firebug) at various different times and see whether it's worth keeping for you.
  • Mini... know & love firebug, but I don't think it will be useful here...

    Firebug measures at the client level, not the server level. Connection latency will
    distort the measurements... local/browser caching further limits the usefulness
    of any timing info gathered.

    In WordPress there's a function get_num_queries which lists all queries performed
    to create the page. Right now we (I) have little clue which add-ons are very DB
    intensive. It's just useful info to have (see recent discussion on ISP that complaining
    about server load, which was negated as soon as the discussion overview add-on
    was removed).

    The Timer add-on provides some info, but I could use more...
  • the advanced php debugger looks promising:
    APD is the Advanced PHP Debugger. It was written to provide profiling and debugging capabilities for PHP code, as well as to provide the ability to print out a full stack backtrace. APD supports interactive debugging, but by default it writes data to trace files. It also offers event based logging so that varying levels of information (including function calls, arguments passed, timings, etc.) can be turned on or off for individual scripts.
Sign In or Register to comment.