Re: [Devel] 2.1.9 Tagged in CVS

[Antoine Leca]

Salut David,

On Thursday, June 24, 2004 9:03 AM, David Turner va escriure:
> I've also used kcachegrind to visualize the bottlenecks with various
> benchmarks. This allowed me to spot that:
>
> - before changing the list of drivers, 58% of the time taken to open
>    a font file was taken by "memset". This resulted from the fact that
>    FT_Alloc does clear the allocated block, which isn't always
>    necessary (especially for large ones, like in the PCF/BDF/GZip
> drivers).
>
>    I have thus introduced new functions FT_QAlloc and FT_QRealloc
>    (the Q stands for "Quick"), with corresponding macros and a few
>    modifications to the sources (more will follow)

Hmmm, this looks like there is an opportunity for improvement here.

I do not know very well if and how it works, but naively I would expect a
possible implementation of FT_Alloc to mmap()s /dev/zero: i.e., the call
will just initialize the page tables to be demand-load, with initialisation
later provided by a device that just zeroes the page (in kernel mode) when
needed. Certainly the benefit would be noticeable on any paging system (too
bad mmap(), much less /dev/zero, are not standard. Win32 has VirtualAlloc,
which does the same thing, but is quite a different API.)

BTW, this is perhaps a good overall optimisation for memset(p,0,BIG) inside
libc as well; but that is another story entirely ;-).


>    Given that we only use this for small PCF or BDF files, it
>    shouldn't be a big problem in practice (and who does use large
>    bdf.gz files anyway :-)

[ Assuming David is not in fact joking about BDF with regard to PCF... ]

Eastern Asia people, where >20,000 characters fonts predates vector font
technology, and _might_ be still prevalent/important on today's boxes. Note
that my records are they rather used pcf.Z fonts

I shall defer to people knowing reality here.



Antoine