Subject: property caching
From: Tomas Frydrych (email@example.com)
Date: Tue Mar 20 2001 - 14:40:16 CST
> Paul> The idea of caching run-level props is to mimimize the amount of
> Paul> code it takes to draw, which ought to be the most common
> Paul> operation in a GUI app. Or are you seeing nasty delays during
> Paul> typing?
> Ah! These are cached copies of properties. I'm sorry if I offend, but
> I just have to say: how incredibly crude :)
> So there's a nice indexed property array with all the info needed to
> render a Run. To speed up rendering, instead of improve the way to
> access this information, it gets copied to each and every Run.
> That's like reverse-caching (assuming "normal" caching is a way of
> concentrating the information you access often in the same location -
> here it gets spread out :)
We do not just cache properties in the runs. What we do in the
runs is that we also translate the properties from their string
representations into more handy numerical values; without it we
would have to use strcmp every time we need to evaluate any
property of the run, and that would be a performance disaster. One
possible speed up would be to move from storing the properties as
raw xml to numerical representations.
How feasible this would be I am not sure. There is no doubt in my
mind that we would get leaner and swifter AW this way: the
memory requirements of the AP table would be smaller and the AP
lookups would be faster, plus we could get better type safety than
strings provide. On the other hand, we would have to rewrite
everything that queries/sets properties, which is quite a bit.
This archive was generated by hypermail 2b25 : Tue Mar 20 2001 - 14:41:29 CST