From shywolf9982 at gmail.com Mon Apr 2 00:41:33 2007 From: shywolf9982 at gmail.com (Simone Deponti) Date: Sun, 1 Apr 2007 22:41:33 +0000 (UTC) Subject: [Kss-devel] Inline editing and related issues Message-ID: Hello list, I'll do a quick recheck of the status of inline editing. Actually it works properly with correct key bindings (enter -> submit, esc -> cancels) on: * Internet Explorer 6 * Firefox 2.0 * Safari Actually, this is done in a pretty brutal and suboptimal way, in my own opinion. We previously had the issue that we couldn't prevent the default behavior of Safari when the user hits enter, and for what I've been able to see, it happens that in Safari, we have a default event for keyUp, keyPress and keyDown. Also, seems like that the default behavior for the events listed above is *NOT* submitting the form, but rather issuing a "submit button click event". I'm not entirely sure it is actually like that, I didn't do a deep research into the stuff and I might have had hallucinations or maybe I assumed too much alcohol or who knows, but basically we wanted to make it "just work (tm)" so it's all good. I however think we should review it somehow, and there are some steps I think we should take (and that I'll probably take personally, but that depends a lot on how much time I have). I think we should: * Research if other frameworks/applications/whatever encountered this issue already and how they take care of it. * See if the WebKit guys knows anything about it (it's an opensource project after all). * See if we should improve our javascript accordingly to the previous points. Ok, I think that's all for it. If anybody has suggestions or whatever, I'd be really glad to hear them. Cheers Simone From hedley at upfrontsystems.co.za Mon Apr 2 11:24:15 2007 From: hedley at upfrontsystems.co.za (Hedley Roos) Date: Mon, 02 Apr 2007 11:24:15 +0200 Subject: [Kss-devel] getHtmlIdSelector and cssQuery speed issues Message-ID: <4610CBBF.5030805@upfrontsystems.co.za> I have a script which does ten calls to getHtmlIdSelector and then subsequent ksscore.replace(Inner)HTML's. According to firebug the cssQuery function gets called 197764 times. It is extremely slow. When I modify the script to only do two getHtmlIdSelector's cssQuery gets called 23858 times. The rest of the javascript functions use less than 2% of the execution time. So, why does this happen? cssQuery does not seem to slow by itself. It is the number of times is gets called that hurts my browser. My current workaround is to update larger parts of the page than needed, thereby reducing the number of getHtmlIdSelector's at the expense of sending more data back to the client. From ree at ree.hu Thu Apr 5 06:36:30 2007 From: ree at ree.hu (Balazs Ree) Date: Thu, 5 Apr 2007 06:36:30 +0200 Subject: [Kss-devel] getHtmlIdSelector and cssQuery speed issues References: <4610CBBF.5030805@upfrontsystems.co.za> Message-ID: On Mon, 02 Apr 2007 11:24:15 +0200 Hedley Roos: > I have a script which does ten calls to getHtmlIdSelector and then > subsequent ksscore.replace(Inner)HTML's. > > According to firebug the cssQuery function gets called 197764 times. It > is extremely slow. When I modify the script to only do two > getHtmlIdSelector's cssQuery gets called 23858 times. The rest of the > javascript functions use less than 2% of the execution time. That's a little bit too much and it needs an investigation. It should not be called that many times. (maybe, cssQuery is recursive? Or is there a chance your insertions are recursive?) > So, why does this happen? cssQuery does not seem to slow by itself. It > is the number of times is gets called that hurts my browser. cssQuery is very slow by itself in the way we have to use it. Unfortunately it's a known issue that cssQuery is buggy, and also we either need to replace it with another library, and/or rewrite it so that we can use it properly. One issue is that when binding the inserted nodes, we would need to search selected nodes only in the subtree we insert into the dom. This is however not supported properly. So even if we just insert a single node, we are forced to do a query in the entire document. This is repeated for every kss rule that is defined. So yes, cssQuery is the major reason for slowness of binding. There may be others. However this yet does not explain the number of calls for me. > My current workaround is to update larger parts of the page than needed, > thereby reducing the number of getHtmlIdSelector's at the expense of > sending more data back to the client. The thing that I don't understand is, that getHtmlIdSelector has nothing to do with cssQuery, and I don't see how they relate. -- Balazs Ree From hedley at upfrontsystems.co.za Thu Apr 5 11:31:48 2007 From: hedley at upfrontsystems.co.za (Hedley Roos) Date: Thu, 05 Apr 2007 11:31:48 +0200 Subject: [Kss-devel] getHtmlIdSelector and cssQuery speed issues In-Reply-To: References: <4610CBBF.5030805@upfrontsystems.co.za> Message-ID: <4614C204.7000503@upfrontsystems.co.za> > The thing that I don't understand is, that getHtmlIdSelector has nothing > to do with cssQuery, and I don't see how they relate. You are right - it has nothing to do with it. Only two places in azax relate to cssQuery: resourcedata.js and selectorreg.js. I have found that mergeForSelectedNodes in resourcedata.js does some kind of two-pass sweep. It calls kukit.dom.cssQuery twice the number of times as the number of defined KSS rules. That is the expected bahaviour. But getHtmlIdSelector or something triggers some other state which results in repeated calls to cssQuery (the packed one that ships with kukit). I don't think it is your code that is responsible for that but rather something in CMFPlone. Two days of research and I'm still struggling to find a solution. I now do my testing on the plone_control_panel page since it is usually the same accross Plone installations. I'm about to replace the packed cssQuery with the unpacked one so that Firebug can give better feedback (the eval in cssQuery.js obfuscates the function name in Firebug). Then I'll compare a non-azax Plone with an azax Plone and post the Firebug profiles. From hedley at upfrontsystems.co.za Thu Apr 5 11:56:30 2007 From: hedley at upfrontsystems.co.za (Hedley Roos) Date: Thu, 05 Apr 2007 11:56:30 +0200 Subject: [Kss-devel] getHtmlIdSelector and cssQuery speed issues In-Reply-To: <4614C204.7000503@upfrontsystems.co.za> References: <4610CBBF.5030805@upfrontsystems.co.za> <4614C204.7000503@upfrontsystems.co.za> Message-ID: <4614C7CE.7080308@upfrontsystems.co.za> All these tests performed on plone_control_panel (debug mode on for Zope, portal_javascripts and portal_css). PloneAzax installed: 9259 javascript function calls, 316 ms PloneAzax and my products's KSS sheets (contains 28 KSS rules): 52583 javascript function calls, 1719 ms No PloneAzax: 212 javascript function calls, 20ms Worst of all, while the javascript is executing the browser is unresponsive. From hedley at upfrontsystems.co.za Thu Apr 5 12:04:59 2007 From: hedley at upfrontsystems.co.za (Hedley Roos) Date: Thu, 05 Apr 2007 12:04:59 +0200 Subject: [Kss-devel] getHtmlIdSelector and cssQuery speed issues In-Reply-To: <4614C7CE.7080308@upfrontsystems.co.za> References: <4610CBBF.5030805@upfrontsystems.co.za> <4614C204.7000503@upfrontsystems.co.za> <4614C7CE.7080308@upfrontsystems.co.za> Message-ID: <4614C9CB.8010309@upfrontsystems.co.za> I found a possible solution! Instead of defining a class as .klass in the KSS, rather do img.klass or whatever tag is relevant. This drops the number of Javascript calls by 1082 for me. From ree at ree.hu Mon Apr 30 13:11:30 2007 From: ree at ree.hu (Balazs Ree) Date: Mon, 30 Apr 2007 13:11:30 +0200 Subject: [Kss-devel] kss performance improvement Message-ID: 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 From gotcha at bubblenet.be Mon Apr 30 13:45:56 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Mon, 30 Apr 2007 13:45:56 +0200 Subject: [Kss-devel] kss performance improvement In-Reply-To: References: Message-ID: <4635D6F4.50203@bubblenet.be> Balazs Ree wrote: > > 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