On Aug 7, 2009, at 8:22 12AM, Stéphane Ducasse wrote:
Thanks thanks thanks. Henrik this is cool that we get such an analysis. Do you have an idea of the memory usage too :)
Stef
On Aug 6, 2009, at 4:24 PM, Henrik Johansen wrote:
Without a memory allocation profiler, anything becomes a(n educated, at best) guess. Mine would be the glyph cache lookup code, where 95% of the "rendering" time is spent. For _each_ character rendered a loopup is made in a 3-layer dictionary to find the glyph: 1. By font - hashed by font size, so if f.ex you're using 2 fonts of size9, you're practically guaranteed collisions... 2. By character code. - 99% of the time, this will be in ascii range, might be a good idea to use a special class with array access for values 32-255, and a dict lookup just for the rest 3 By color/subpixel-position... - Character widths are also stored here. (but color/subpixel position make up 98% of these lookups) - Hashed by color value + subPixelPosition << 32, so you're always doing LargeInteger comparisions for lookups. Yay. - The color value calculation goes red << 24 + green << 16 + blue << 8 + alpha, so does 4 LargeInt additions instead of 3 SmallInteger adds and 1 LargeInt. Yay. Also, every time a cached glyphs is accesed, it is pushed to top of a LinkedList, the only thing I can see this LinkedList currently used for, is easy access to all the CacheItem instances when removing them all... The idea was probably to sometimes just remove the least used ones, but that's currently not done, as far as I can see. So in conclusion, the cache strategy in FreeType could benefit from a major rethinking :) Cheers, Henry