The 6.x boost.module code size has increased significantly to become the most expensive php compiled / opcode, at least from the list of modules I have installed including cck and views.

Consider the following :

boost "5.x-1.0":
==========
367 lines of code - source code size 13K

cached opcode size (reported by xcache) => 60K
--(boost.api.inc and boost.helpers.inc adding upto another 62K)
TOTAL opcode size in the 122k range

boost "6.x-1.18"
==========
4617 lines of code - source code size 165K

cached opcode size (reported by xcache) => 839K
--(boost.admin.inc adding upto another 310K)
TOTAL opcode size in the 1.1mb range.

The only opcode cache size that comes next to it is views/includes/admin.inc at 583K and common.inc at 474K (as reported by xcache opcode cacher for PHP 5.2).

A suggestion I have is:

If possible to logically contain some functions/codes as distinct features that could be optionally checked on/off and if those could be segregated into sub-modules which is only enabled when using the additional features. Unless those sub-modules are checked the code footprint does not make it into thread/cache. This way we can maintain the core power of boost functionality (serving up static html files instead of processing php/sql) without forcing unnecessary code bloat from additional / incremental benefits based features. (features sub-modules could be for things like : gzip compression, JSON/XML, CSS/JS, URL variables) - I have not gone thru all code, but just looking at the long laundry list of options to toggle on/off from boost settings gives me a feeling this may be possible.

I may consider putting some functions away into sub-modules for my installation to avoid the code footprint adding to the thread size, but then again that will break upgrade-ability for me and may not be worth saving a few 100K's.

BTW I do not mean to be critical at all. I think Mike has done an excellent job along with others who help maintain and move Arto's boost forward and I consider it as one of the key arrows in Drupal's quiver when it comes to performance. I am just voicing a possible concern on the trade-off between features vs. code-bloat, but also where we can have both a la carte style without sacrificing the minimalistic approach. Thanks.

Comments

mikeytown2’s picture

mikeytown2 commented

7.x version is smaller and I plan on keeping it that way. Boost is what I would call feature creep; with some spinoffs being more successful then others.
http://drupal.org/project/advagg - Removes the need to cache css/js in boost.
http://drupal.org/project/httprl - The basics of the boost crawler & code from advagg as well.
http://drupal.org/project/expire - Haven't gotten any time to work on this at work so it hasn't gone very far.

Point being, I know this (code bloat) is a problem. I'm currently ignoring the problem. We do use boost at work for its expiration logic so it's not dead... just minimally maintained at the moment. Working on the expire module is on the todo list, after a couple of other things.

Caching JSON/XML/HTML takes about 10 lines of extra code to do, and in 7.x I actually made it a hook where you provide some simple parameters to define new storage types. Gzip in 7.x has also been cleaned up. Issue with 6.x is it grew organically, adding things on as it became apparent that they were issues.
Taken from boost_boost_storage_types()

...
  $types['text/xml'] = array(
    'title'           => t('XML'),
    'description'     => t('XML output, usually a feed'),
    'extension'       => 'xml',
    'enabled'         => FALSE,
    'gzip'            => TRUE,
    'lifetime_max'    => 3600,
    'lifetime_min'    => 0,
    'comment_start'  => '<!-- ',
    'comment_end'    => ' -->',
    'variants'        => array(
      'application/xml',
      'application/rss',
      'application/rss+xml',
    ),
  );
...

Point being, the sub-systems of boost is where the code got big. Cache expiration & the crawler is probably two thirds of the total code base; and I've started various projects that can eventually be used to shrink boost back down. Legacy code adds up as well.

If you look at the project commits I've done here on drupal.org I like to focus on one project at a time as this makes working on that project much more productive. Boost will eventually be a focus; just we have bigger pain points to deal with besides code bloat.

bgm’s picture

bgm commented
Version: 6.x-1.18 » 6.x-1.x-dev
Status: Active » Fixed

Another option to reduce the code might be to split out the UI code (for the advanced configurations) in a submodule.

However, I don't mean to be overly aggressive with closing issues, but I think it's unlikely that this will be done in 6.x-1.x (unless someone steps forward and sends patches) and since Mike mentioned he intends to keep 7.x-1.x minimal, I guess we can mark this as fixed?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.