Subject: Re: Win32 performance results
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Wed Mar 07 2001 - 16:50:40 CST
paul> In the mean time, I was actually thinking it might be worth
paul> updating the existing logic to cache the results of those Prefs
paul> calls, since the specific Prefs used vary rarely, if at all,
paul> during a session. However, I have no idea whether we'd want the
paul> GR_Graphics class to have a prefs listener to invalidate this
paul> cache. Of course if remapGlyphs gets called rarely, then this
paul> optimization isn't needed.
The tables already are cached. The two calls are used to make sure
that the preference scheme hasn't changed. (If I were implementing
this today, I definitely would use a listener. However, I haven't
looked to see if one can "get at" all that's required from that
location. Probably can. So, someone who is a performance tuning
eager beaver and who believes this particular item is worth their
attention can change this and make it all go away without hearing a
lot of whining from me.)
One of the two calls mentioned, getPrefs() is just an accessor method
for a private member variable. So, it could be eliminated if someone
cared (I was just following a pattern), or maybe it and a billion
other accessors could be inlined. The other call is just to get a
pointer to the current preferences scheme. Probably some object
pointer traversal but nothing fancy. All this is moot if things are
converted to a listener for preferences changes.
paul> PS: Speaking of remapGlyphs, did you notice the leak I mentioned
paul> in the following thread?
paul> http://www.abisource.com/mailinglists/abiword-dev/01/February/1022.html
paul> AFAIK, it's the only leak we have now on Win32 in a "launch and
paul> close" scenario.
I didn't notice it except to take your word for it in the cited
message. Anyone interested can feel free to change it. It is too dim
a blip on my radar scope right now.
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Wed Mar 07 2001 - 17:49:29 CST