[Kss-devel] kss performance improvement

[Godefroid Chapelle]

Balazs Ree wrote:

<snip>

> 
> 5. Logging and packing issues
> 
> We tried to disable logging of kss on Firefox, and it is a cleanly 
> noticable speedup. At the moment it is possible to switch off firebug 
> when you want to see the real speed of the system. However I also 
> realized that we are doing a lot of parameters checking that is a 
> substantial burden of the code. It is good that we have this because it 
> results in robustness and debuggability, but in return it affects both 
> size and speed.
> 
> So we could make a "development" and "production" version of the kss 
> javascript, and the production version would have all logging and error 
> checking stripped. This means that on the production system you would see 
> no sensible error message, just a breakage.
> 
> There are two issues that are important to note about this: 
> 
> a/ First, it would be desirable to have the two versions autogenerated. 
> Dean Edward's packer already contains a ;;; construct for this, lines 
> starting this way are stripped out in the packed version but present in 
> the unpacked one. We could implement this, or a similar feature in the 
> packer. (Godefroid does not like the ;;; but I can't figure out anything 
> better myself.)

I do not remember having told that I did not like this.

I think it makes sense to use this type of constructs...

> 
> b/ Second, I find it inevitable that after this (since we loose virtually 
> all debugging on the production system) we need a way to change from 
> production to development mode from the client, without changing setting 
> on the server. One way to do this is with a cookie that the browser sends 
> up in development mode. The cookie can get toggled from the ui. We must 
> have this if we want to be able to see what gets broken in a system in 
> production, restarting or putting RR into debug mode even for a short 
> time, is not an acceptable option imo.
> 
> I will make some experiments with this on a dedicated branch, to see how 
> much KB the commentifying would bring us.
> 
> 
> 
> Summary.
> 
> We had slightly different results than we expected, but we certainly 
> succeeded to explore the problems deeper. At the moment only point 2. can 
> go to the release to be done today, all the rest is on a branch and will 
> be merged any time after the release.
> 
> Please help testing the branch of kss.core on:
> https://codespeak.net/svn/kukit/kss.core/branch/performance_improvement
> 
> It also contains a few other fixes, (ree-event-load-cleanup merged in) 
> most notably the "load" event's current functionality has been split to a 
> "load" and "iload" events. This may effect the loading of iframe editors, 
> most notably kupu, so in case you notice an error or difference, please 
> notify us.
> 
> If you want to test base2, it is not yet integrated to Plone, you need to 
> manually add the resource of ++resource++base2-dom-fp.js to 
> portal_javascript. If it is enabled, it will be picked up and used by 
> kss. Don't disable cssQuery, as it is used by other Plone components that 
> are not switched over yet, but this may happen soon too on the branch.
> 
> We will continue to move on with these subjects.
> 

Thanks for this nice summary.


-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be