[Kss-devel] kss performance improvement

[Balazs Ree]

Last weekend we had a mini-sprint with Jeroen Vloothuis on performance 
improvement of kss. We skipped the otherwise important question of code 
size optimization, and tried to figure out what other factors can affect 
the speed of loading the pages. Subjective experience of the user when 
loads up an average Plone page would matter, we would like to have the 
best user experience.

1. Changing the cssQuery to Dean Edwards's new base2 library.

http://dean.edwards.name/weblog/2007/03/yet-another/

The motivation is we need to replace cssQuery we use, both because it is 
buggy, and because we call it many times.

We succesfully hooked base2 instead of the old cssQuery. For a complete 
transition, we would want to get rid of the old cssQuery, that means we 
need a lightweight wrapper (easy). We also would want to separate the 
part that is important for us from base2 and repack it.

However we experienced problems and found at least a bug in base2. This 
means there can be others, and since other javascript components use 
cssQuery too, we need more testing before we break basic functionality of 
Plone without even noticing it.

What's more, when we tried to compare the speed of base2 and cssQuery, 
actually we found base2 six times slower then cssQuery. This is much in 
contrary with the benchmarks on  
http://homepages.nildram.co.uk/%7E9jack9/base2/speedtest/ .

If anyone can do benchmarking on their system, please do. We have 
theories but nothing concrete.


2. Changing the binding processing in the newly inserted html parts

The newly inserted parts got their kss events bound in a batch now. This 
means that if more commands that insert new html are received from the  
server, we call the binding only once instead of many times (as before). 
With the current cssQuery usage this is a clean performance win.


3. Figure out if the current usage of onDOMLoad can be changed.

Kss startup is triggered by the onDOMLoad event in Plone. We experimented 
with changing it back to the normal window onload event, but we saw no 
noticable difference.


4. Benchmarking.

This is a general issue. We benchmarked with two methods: Firebug's 
javascript profiler, and kss's logged time measurements. Both were giving 
very inconsistent results: for example the speed of a given operation 
fluctuates between 300 and 1100 milliseconds. Which is first difficult to 
compare and also raises the suspicion that we are not measuring what we 
want.

We would need to introduce a way of doing automated benchmarks in a 
similar way how we planned the yet unimplemented "fourth test runner". 
(This would be a runner that can remote control kss on a direct level, 
and different kss internals could be checked and benchmarked with it.) 
Automated benchmarks would have the advantage of statistics. We would 
need at least 50 runs of the same operation to have credible results.

If anyone has suggestions, please, let us know.


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.)

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.

-- 
Balazs Ree