On Friday, August 10, 2018 at 9:04:34 AM UTC-5, Edward K. Ream wrote:

This branch passes all tests, and I am happily eating my own dog food.
>
> I would like to test this branch a few more days before merging it into 
> devel.
>

Rev 401457f7e fixes a serious bug in qtree.yieldVisible.  The new code is 
necessarily slower than the old, but qtree.yieldVisible is still about 10 
times faster than the testing generator that simply calls p.moveToVisNext().

Rev d01823f0d fixes (again) the bug that caused expand-all to redraw the 
screen way too many times.

Naturally, the total tree redrawing code won't be 10 times faster than the 
old, because much code remains in common.

Actual comparisons of the drawing code itself are dicey, because devel 
redraws the screen too many times when doing an expand-all command.  Adding 
some throw-away tracing in devel gives this when doing expand-all in 
leoPy.leo:

drawTopTree 0.354 sec
drawTopTree 0.403 sec
drawTopTree 0.379 sec
drawTopTree 0.465 sec
drawTopTree 0.462 sec
drawTopTree 0.413 sec
drawTopTree 0.465 sec
drawTopTree 0.415 sec
drawTopTree 0.465 sec
drawTopTree 0.412 sec

All this is for a *single* expand-all.  In contrast (for rev d01823f0d), 
expand-all in fast-draw2 reports:

drawVisible 9427 nodes, 0.312 sec.

Obviously, this is a huge improvement over the code in "devel", but the 
actual fundamental difference in drawing speed isn't yet clear.  To measure 
this, I made a throwaway change to drawVisible, having it call 
slowYieldVisible rather than yieldVisible.  The result was:

drawVisible 9437 nodes, 1.035 sec

So yieldVisible, all by itself, triples drawing speed in fast-draw2.

*Summary*

The fast-draw2 branch does expand-all about 10 times faster than the devel 
branch. In approximate order of importance, the reasons for the improved 
speed are:

1. The fast-draw2 branch avoid redundant redraws, which was, all by itself, 
a huge performance bug.

2. Using yieldVisible instead of slowYieldVisible triples the overall 
redraw speed in fast-draw2.  The added complexity of yieldVisible is thus 
fully justified.

3. Putting all the new redraw code in a tight loop has the least effect. 
Happily, the new code is simpler than the old.

Considering the bugs fixed today, we should have several more days of 
testing before merging fast-draw2 into devel.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to