Rev 5480: disabled color caching: please test

[Edward K. Ream]

Rev 5480 contains new, *disabled*, color caching.  To enable, set cache_color_info = True in leoGlobals.py.

Color caching speeds up coloring of previously-colored nodes by about a factor of 5.  Otoh, color caching increases memory usages while Leo is running, but probably not by an horrendous amount.

I would appreciate you intrepid testers report your experiences with color caching enabled.  Thanks.

Edward

[Edward K. Ream]

On Wednesday, October 3, 2012 8:49:57 AM UTC-5, Edward K. Ream wrote:

> Color caching speeds up coloring of previously-colored nodes by about a factor of 5.

Better measurements indicate that cached coloring is a little less than twice as fast as uncached coloring for large nodes.  This isn't a trivial, but it is not as much as I had hoped. I'm not sure the speedup is worthwhile.  Please let me know what you think.

Edward

[F.S.]

Running 5481 on file with large nodes. set g.cache_color_info to True; removed @killcolor, first impression large nodes switching seems sluggish as ever. But oh wait! There is significant improvement if I come back to a node that was previously selected. Of course! At first time selection the cache is still cold! 

The memory usage increase seems fairly benign for today's computers. For large nodes the speedup is quite significant. Could this feature be turned on as a directive like @killcolor. So we can just @cachecolor to enable color caching at a large node (and its children).

Another observation:

With caching turned on, if I @killcolor a node, the sub nodes that were visited already maintain their cached colors while the unvisited nodes don't have color. Interesting interaction of features here.

[Edward K. Ream]

On Wed, Oct 3, 2012 at 10:25 AM, F.S. <speec...@gmail.com> wrote:

> For large nodes the speedup is quite significant. Could this feature be turned on as a directive like @killcolor.

Excellent idea. @cachecolor and @nocachecolor will allow node-by-node
control. We can then eliminate the g.cache_color_info without
affecting Leo's default operation.

> Another observation: With caching turned on, if I @killcolor a node, the sub nodes that were visited already maintain their cached colors while the unvisited nodes don't have color. Interesting interaction of features here.

Hmm. You could call this a bug. I'll look into it.

Edward

P.S. I am not very happy with the actual details of the color data is
cashed. Today, I was just interested in creating the infrastructure
needed to save and restore data.

Now that the infrastructure mostly works, it's time to see if I can
improve the original prototype. At present, the save/restore code
assumes that some underlying C++ data will disappear when the
QTextDocument changes as the result of switching nodes. Indeed,
earlier drafts of the code took a hard Python crash--presumably for
just this reason.

My present mental model is that the QTextLayout is freed when
switching nodes. That's why write_colorizer_cache laboriously (and
incompletely) copies data from layout.additionalFormats(). Naturally,
what I really would like to do is to hold these additionalFormat's in
memory, but I'm not sure whether that's possible. Perhaps the C++
sources will provide some useful clues.

EKR