On Fri, 2005-12-09 at 16:07 -0500, Bennett Helm wrote: > On Dec 9, 2005, at 3:03 PM, Martin Vermeer wrote: > > > On Thu, Dec 08, 2005 at 12:31:40PM -0500, Bennett Helm wrote:
... > > Bennett, > > > > the attached should produce a noticable speedup. > > > > (Lars likes simple patches :) > > Well, I'm comparing apples and oranges a bit, but I'm not noticing > much of a speed-up. > > I've applied your patch to the version of lyx I compile with gcc-4.0 > (because the gcc-3.3 version I'm currently using for profiling). > Comparing that against a stable gcc-3.3-compiled version (without > profiling info and otherwise configured identically), I don't notice > any difference just by typing. > > Being a bit more systematic: When I type a sentence into a long > paragraph -- the same conditions under which it took me 8 seconds to > type and lyx (gcc-3.3) 16-17 seconds to display -- it takes 15 > seconds to display with the patched version. I've done it several > times with reasonably reliable results, so I think it is fair to say > there is a minor speed-up. > > Using Quartz Debug to look at window refreshes, I don't notice any > difference. > > Finally, I applied the patch to the version of lyx compiled with > gcc-3.3 with profiling info, ran Shark (in the same way I did > before), and placed the report here: <http://edisk.fandm.edu/ > bennett.helm/LyX/shark-profile-2.txt.zip>. > > Bennett This is a bit strange. However, the patch eliminates quite a number of unnecessary paragraph rebreaks and screen renderings. According to my lyxerr instrumentation, without the patch, when you insert a character, LyX - rebreaks the cursor paragraph, twice - rebreaks the ones immediately above and below - rebreaks all paragraphs visible (or nearly-visible) on-screen. (The _total_ number of rebreaks for the paragraph containing the cursor is thus 3, and for the ones immediately above and below, 2) - renders the cursor paragraph, and - renders once more the whole screen (definitely a bug! I thought we had nailed that one). With the patch, we have - rebreaking cursor paragraph, twice - rebreaking paragraphs above and below. - Rendering only the cursor paragraph. According to this logic, the only situation in which the patch would not speed up things much, would be if - the paragraph occupies the whole screen, or more (and remember, we are talking _outer text_ here; so an inset on its own counts as one paragraph), - the paragraphs immediately above and below are also big, and - the time taken by rendering is relatively negligible (I could imagine this, e.g., if rendering events are queued, and the queue is optimized by throwing out events that will be overdrawn anyway. Does the X server work show up in the profile BTW? I suppose not) ...and even in that extreme case, the gain would be 20% (four rebreakings instead of five). So there must be another bottleneck somewhere. Yet based on my tests I believe the patch is sensible and will normally prevent a lot of unnecessary CPU cycles. Pity it's so hard to measure. I propose to check it in. - Martin
signature.asc
Description: This is a digitally signed message part
