Re: anyone notice speed of 2.17.95 on Windows ?

[Keith OHara]

On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup <address@hidden> wrote:

> "Keith OHara" <address@hidden> writes:
>
> > The last time we had a doubling of time required on Windows relative
> > to Linux, issue 1926, it was repeated calls to find_by_name() that go
> > through Pango to the font server.
> >
> > Here the outlines seem to be properly cached; it looks like each text
> > glyph is looked up just one extra time.
>
> Once every time it is written, or once per document?  And what does
> "just one extra time" mean?  One extra per which occasion?

After a brief look at the code, it looked like for each glyph being laid out 
there is one extra call of Open_type_font:: or Pango_font::name_to_index(), 
which is the function called by find_by_name() that caused the extra time with 
issue 1926.

That is, for every 'mf' in the piece, we look up two glyphs by name 'm' and 'f' 
from the font to get a skyline for the 'mf', each skyline is built just once.  
The look-ups are extra over those used to implement the stencil.

One extra lookup per glyph might be enough to explain the difference.  We need 
to look up the glyph to get a skyline, but maybe could cache its index into the 
font in the stencil.

What did you mean to suggest here? :
> > > In this case, the answer is to cache frequently accessed
> > > information instead of requesting it again and again.


> > The call the to FreeType glyph-outline code might cause the extra
> > time, or maybe Guile is less efficient on WinXP, as every nook and
> > cranny in every letter is represented in the skylines objects in
> > Scheme.
>
> If there are differences in speed, I can't imagine them to be in
> anything but possibly garbage collection/allocation, and it seems
> unlikely that they would not then have been apparent with other uses.

Probably true.  I mentioned these possibilities after noticing that there are 
quite a few boxes required to represent the outline of each letter..

What did you mean to suggest here? :
> > > Maybe caching in unsuitable form?  Cached data should be in a form
> > > directly usable for processing (with some possible tradeoffs between
> > > memory impact and unpacking speed), not in the form that
> > > function/library/system calls will return it.