[vwnc] huge font cache
Locked
 
|
Hi list,
i just had the problem that highlighting a method took nearly a second for like 20 lines of code (even longer if there was a breakpoint in this method). I profiled it and found out that there was a fontpolicy with a fontCache that had over 12000 entries. I reset the cache and code highlighting was as fast as it used to be. I just did some quick testing and noticed that the fontcache grew rapidly if I set a breakpoint into a method and deselect/select the method. Every time I did this redisplay, the cache was grew with lots of LeadingInsert fontdescriptions from Extra Emphasis. Kind Regards Karsten -- Karsten Kusche - Dipl.Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Karsten,
couple of years ago the Joachim Geidel posted a description and fix for the font related memory leak:( there was a proposed fix attached as well) >> > * From: "Terry Raymond" <[hidden email]> >> > * Date: Fri, 15 Jul 2005 10:29:25 -0400 >> > >> > It seems that VW has a memory leak with respect to open fonts. >> > The open font handle registry used by HostGraphicsDevice is >> > a subclass of IdentityDictionary. However, the keys used >> > for the fonts are strings which are built from the font >> > description, so a font lookup will not retrieve the existing open >> > font but will allocate a new font. >> > >> > When I inspect openFonts I find that I have several entries >> > for arial~16~400~0~0~0~ansi~0. > > This probably explains some problems in the system we are currently > working on - primitive failures while allocating Pixmaps, fonts, opening > Windows. They are probably due to running out of handles, but we were > not able to reproduce this situation. Looking into HostGraphicsDevice > revealed that the parcel ColorEditing, which is loaded in our > development environment, patches the way fonts are allocated in an > attempt to fix the problem Terry reports. Of course, ColorEditing is not > loaded in the deployment image... > > A patch which also takes into account that concurrent processes might > try to allocate fonts is attached to this message. > > After loading the patch, you should save and restart the image. This > flushes the openFonts registry of the default Screen. > > When using ColorEditing, you should > * load the patch AFTER loading ColorEditing or > * use a version of ColorEditing where you have removed the override of > HostGraphicsDevice>>fontNamed:fromClass:encoding:. > > The patch prevents errors when the original ColorEditing is loaded after > the patch by looking for Symbol names as well as Strings in > HostGraphicsDevice>>unregisterFontNamed:. > > Use it at your own risk - it seems to work, but I have not yet tested it > a lot. Don't use it to control nuclear power plants... ;-) > > Joachim Geidel Karsten wrote: > Hi list, > > i just had the problem that highlighting a method took nearly a second > for like 20 lines of code (even longer if there was a breakpoint in this > method). I profiled it and found out that there was a fontpolicy with a > fontCache that had over 12000 entries. I reset the cache and code > highlighting was as fast as it used to be. > > I just did some quick testing and noticed that the fontcache grew > rapidly if I set a breakpoint into a method and deselect/select the > method. Every time I did this redisplay, the cache was grew with lots of > LeadingInsert fontdescriptions from Extra Emphasis. > > Kind Regards > Karsten > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Mark,
Joachim's fix didn't help. I had a look again and noticed that the ExtendedFontDescriptions that are used as keys for caching all have an OpaqueImage that is used for their hash. The image looks the same in all intances but it's always a different image. That's why the hashes are not equal, too. Maybe the font description shouldn't carry the image that is used for the font, but then i guess it could be hard to tell the font which image to use. Karsten Mark Pirogovsky wrote: > Karsten, > couple of years ago the Joachim Geidel posted a description and fix > for the font related memory leak:( there was a proposed fix attached > as well) > >>> > * From: "Terry Raymond" <[hidden email]> >>> > * Date: Fri, 15 Jul 2005 10:29:25 -0400 >>> > > It seems that VW has a memory leak with respect to open fonts. >>> > The open font handle registry used by HostGraphicsDevice is >>> > a subclass of IdentityDictionary. However, the keys used >>> > for the fonts are strings which are built from the font >>> > description, so a font lookup will not retrieve the existing open >>> > font but will allocate a new font. >>> > > When I inspect openFonts I find that I have several entries >>> > for arial~16~400~0~0~0~ansi~0. >> >> This probably explains some problems in the system we are currently >> working on - primitive failures while allocating Pixmaps, fonts, opening >> Windows. They are probably due to running out of handles, but we were >> not able to reproduce this situation. Looking into HostGraphicsDevice >> revealed that the parcel ColorEditing, which is loaded in our >> development environment, patches the way fonts are allocated in an >> attempt to fix the problem Terry reports. Of course, ColorEditing is not >> loaded in the deployment image... >> >> A patch which also takes into account that concurrent processes might >> try to allocate fonts is attached to this message. >> >> After loading the patch, you should save and restart the image. This >> flushes the openFonts registry of the default Screen. >> >> When using ColorEditing, you should >> * load the patch AFTER loading ColorEditing or >> * use a version of ColorEditing where you have removed the override of >> HostGraphicsDevice>>fontNamed:fromClass:encoding:. >> >> The patch prevents errors when the original ColorEditing is loaded after >> the patch by looking for Symbol names as well as Strings in >> HostGraphicsDevice>>unregisterFontNamed:. >> >> Use it at your own risk - it seems to work, but I have not yet tested it >> a lot. Don't use it to control nuclear power plants... ;-) >> Joachim Geidel > > > > > > > > > Karsten wrote: >> Hi list, >> >> i just had the problem that highlighting a method took nearly a >> second for like 20 lines of code (even longer if there was a >> breakpoint in this method). I profiled it and found out that there >> was a fontpolicy with a fontCache that had over 12000 entries. I >> reset the cache and code highlighting was as fast as it used to be. >> >> I just did some quick testing and noticed that the fontcache grew >> rapidly if I set a breakpoint into a method and deselect/select the >> method. Every time I did this redisplay, the cache was grew with lots >> of LeadingInsert fontdescriptions from Extra Emphasis. >> >> Kind Regards >> Karsten >> > > -- Karsten Kusche - Dipl.Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Andres,
the new hashing implemented on 7.6 can fix this perhaps? ciao Giorgio On Mon, Feb 25, 2008 at 5:29 PM, Karsten <[hidden email]> wrote: Hi Mark, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Giorgio,
At first sight, it seems to me the issue is as described
below... the extended font descriptions don't really differ, but because the
opaque image's implementation of = is really ==, then comparison evaluates
to false even though the bits are the same.
One could go and reimplement OpaqueImage>>= and
OpaqueImage>>hash to go compare and hash the bits respectively.
Certainly the hashing primitives in byte array should provide good quality
results for hashing images. However, I am not sure this is the best course
of action for this particular problem.
For example, if the opaque image is really the same, then
why are there multiple instances of it instead of there being a singleton?
Or, if there really need be multiple such images, why not use wrapping objects
that know how to compare themselves via the class they belong to? In
this way one would not have to modify generic objects with very narrow
applications in mind. For example,
ExtraEmphasesGraphicOfSomeSort
ExtraEmphasesStopSign
ExtraEmphasesGoSign
(I really don't know much about ExtraEmphases, so the above
is just to illustrate the argument --- to reduce complexity by creating more and
more classes to the point that the answer to every method becomes
obvious)
Then,
ExtraEmphasesGraphicOfSomeSort>>=
someOtherSign
^self class ==
someOtherSign class
and
ExtraEmphasesGraphicOfSomeSort>>hash
^self class
identityHash
This would work because the image for each "graphic of some
sort" would be constant across the instances of a given class. If this can
be assumed by construction, then comparing the bits is unnecessary
work.
In this way, since an object aware of its identity and
meaning would exist (as opposed to a more, um, "naive" (?) opaque image), it
would be more natural for the result of the comparison to become evident when
writing the code as opposed to when executing the code. Moreover, images
wouldn't be compared or hashed at all, and thus execution would be even
faster.
At first this may seem like an uncalled-for amount of
work. However, I've seen it pay off so much so often that I've found it
valuable to train myself into just doing things this way by default.
Eventually it becomes natural, and then it switches from being an extra
burden to being an extra benefit basically for free.
Just my 2 cents... hopefully this makes sense and helps
:).
Andres. From: [hidden email] [mailto:[hidden email]] On Behalf Of giorgio ferraris Sent: Tuesday, February 26, 2008 2:43 PM To: Karsten; [hidden email] Cc: vwnc-list; [hidden email] Subject: Re: [vwnc] huge font cache the new hashing implemented on 7.6 can fix this perhaps? ciao Giorgio On Mon, Feb 25, 2008 at 5:29 PM, Karsten <[hidden email]> wrote: Hi Mark, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by giorgiof
On Feb 26, 2008, at 2:42 PM, giorgio ferraris wrote:
> Andres, > > the new hashing implemented on 7.6 can fix this perhaps? It's not really a hashing oversight. Andres did provide a more rigorous hash for the ExtendedFontDescriptions a little while ago, but it's not really going to fix the problem. The problem is that it really does create a new leadingInsert each time. The leadingInsert has no "logical representation" for it's graphic. And the code is implemented calls LeadingInsert stopGraphic, which creates a new image each time. If you're using 7.6 (or beta thereof), a quick fix is to simply modify the LeadingInsert class>>stopImage method as follows: stopImage "UIMaskEditor new openOnClass: self andSelector: #stopImage" <resource: #image> ^[OpaqueImage figure: (CachedImage on: ((Image extent: 16@16 depth: 3 bitsPerPixel: 4 palette: (Graphics.MappedPalette withColors: ((Core.Array new: 6) at: 1 put: Graphics.ColorValue black; at: 2 put: Graphics.ColorValue white; at: 3 put: (Graphics.ColorValue scaledRed: 8191 scaledGreen: 6135 scaledBlue: 6135); at: 4 put: Graphics.ColorValue green; at: 5 put: Graphics.ColorValue red; at: 6 put: (Graphics.ColorValue scaledRed: 4111 scaledGreen: 0 scaledBlue: 0); yourself)) usingBits: #[51 51 18 34 34 36 51 51 51 49 68 68 68 68 67 51 51 20 68 68 68 68 68 51 49 68 68 68 68 68 68 67 20 68 68 68 68 68 68 68 33 17 65 17 65 20 17 69 33 68 68 20 20 20 20 21 36 20 68 20 20 20 20 21 36 65 68 20 20 20 17 69 33 65 68 20 20 20 20 69 33 17 68 20 17 68 20 69 36 68 68 68 68 68 68 64 52 68 68 68 68 68 68 3 51 68 68 68 68 68 64 51 51 52 68 68 68 68 3 51 51 51 69 85 85 80 51 51]))) shape: (CachedImage on: ((Image extent: 16@16 depth: 1 bitsPerPixel: 1 palette: CoveragePalette monoMaskPalette usingBits: #[15 240 0 0 31 248 0 0 63 252 0 0 127 254 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 255 255 0 0 127 254 0 0 63 252 0 0 31 248 0 0 15 240 0 0])))] once The only change is the wrapping of the image code with a [ ] once block. One could store it in an lazy initialized variable otherwise I guess. The main goal is to not keep creating the same image over and over and over again. It does have the nice side affect of not polluting the cache, but is just more efficient for other reasons as well. Less graphics handles. Less time spent creating them. Yada yada. Ideally it would be nice if some of the fonts were not cached at all. These higher level decorations aren't really the kind of thing you want to cache. -- Travis Griggs Objologist "It's [a spec] _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality" - Linus Torvalds _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
I have published a version (43) of EE which should solve the probes
problem. It does not require a once block, so can be used in previous versions. -- Travis Griggs Objologist "HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup of coffee at the same time." - Martin Kobetic _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi Travis,
thanks a lot for the fix!! Kind Regards Karsten Travis Griggs wrote: > I have published a version (43) of EE which should solve the probes > problem. It does not require a once block, so can be used in previous > versions. > > -- > Travis Griggs > Objologist > "HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup > of coffee at the same time." - Martin Kobetic > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > -- Karsten Kusche - Dipl.Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |