Closed Bug 14961 Opened 25 years ago Closed 24 years ago

page takes 60 seconds to load due to Unix font loading

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: dbaron, Assigned: erik)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(2 files)

some stack traces during performance problems (on suspend) showing font loading as the problem
5.75 KB, text/plain
Details
xlsfonts from solaris-2.7
80.00 KB, text/plain
Details 
DESCRIPTION:  The above URL takes about 60 seconds to load on my machine
(details below).  The first 45 seconds of this have near-100% CPU usage.  This
seems to be a useful test case for performance testing - there's something going
wrong here.  This page does take some time to load on other browsers, but not
nearly that much.

The page has a large table that is heavily styled using CSS.

STEPS TO REPRODUCE:  Load http://www.fas.harvard.edu/~dbaron/css/test/results

ACTUAL RESULTS:  Takes 60 seconds to load.

EXPECTED RESULTS:  The fastest layout on the planet :-)

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-09-24-08-M11
 * Linux, viewer, 1999-09-26-08-M11

ADDITIONAL INFORMATION:
My machine is a PII-233 running RedHat Linux 6.0 (with updates), and has 64MB of
RAM and an STB Veliocity video card (I think) using the XF86_SVGA X-server.
Assignee: troy → kipp
Loads reasonably fast for me on Windows. We load the page and then throw
everything away and recreate all the frames (looks like when the linked style
sheet is loaded), which isn't helping performance.

Kipp, you develop on Linux. If this is a problem for you, then maybe you or
another Linux developer can take a look?
On my machine here at home it takes up to 10 seconds to load. Usually faster,
but it depends on how much of the page is loaded before we throw it all away
and recreate the frames...
Whiteboard: [Perf]
Putting on [Perf] radar
On the page http://www.fas.harvard.edu/~dbaron/links/Internet , the horrible
performance (40-60s vs. 5s) seems to be due to the use of the “ and
” entities.  The problem could be the same here, except Troy reports 10s
on NT (does that include network loading?), so there are probably some other XP
issues that could be addressed.  I also don't know if the font performance
should really be that bad (it also could be specific to xfsft vs. xfstt,
although xfsft, which I use, supposedly does a better job with font caching, if
I'm not getting things backwards).  This should probably be split into two
bugs...
It takes both gfontsel and xfontsel about 30 seconds to load
-*-bitstream cyberbit-*-*-*-*-*-*-*-*-*-*-iso10646-1 for the first time, and
less thereafter.  This is likely the problem.  I wonder if there is any way
around this.  I use xfsft, and I added the iso10646-1 encoding manually.
When the font-family list ends with a generic font, I believe the implementation
is supposed to do its best to find *some* font to satisfy the request. Our
implementation enumerates the fonts available on the system, and checks to see
if the required glyph(s) are available within those fonts. Since the Bitstream
font has been made available, it will be loaded and checked.

One possible solution might be to load iso10646-1 fonts last, hoping to find
the required glyphs in other fonts first. How does that sound?
CSS1 and CSS2 seem to suggest that you should even find a character in other
fonts not in the font-family list (including the generic), although it's not
very clear:

5. If there is no font within the family selected in 2, then use a UA-dependent
default 'font-family' and repeat step 2, using the best match that can be
obtained within the default font.

 - http://www.w3.org/TR/REC-CSS1#font-matching

8. If there is no font within the family selected in 2, then use the inherited
or UA-dependent 'font-family' value and repeat from step 2, using the best match
that can be obtained within this font. If a particular character cannot be
displayed using this font, the UA should indicate that a character is not being
displayed (for example, using the 'missing character' glyph).

 - http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm

The solution of checking iso10646 fonts last seems useful.  You seem to be
caching the necessary information already (i.e., it is much faster the second
load - but I didn't try different characters).  However, are there any other,
similar, encodings that should be checked last?
Bitstream is one of the largest fonts that I know of, so iso10646-1 is clearly
a candidate for putting near the end of the list. There are no other huge
charsets, but there are some smaller ones, like the Japanese, Chinese, etc
fonts. Then again, it might be the speed of the TrueType font servers on X that
make it slow (rather than the size). I don't know. We'd probably have to do
some tests to find out what's slow.
Assignee: kipp → erik
Giving this to erik so that he has a bug to close when he's done the performance
work needed to the font picking logic.
Status: NEW → ASSIGNED
Target Milestone: M15
I'll take a look during M14/M15. I don't know yet whether this is something we
can fix. It may have more to do with the font server and/or size of font.
Blocks: 17962
Here is an example where the same symptoms occur with a recent Win32 build.  The
site is http://www.voodooextreme.com.  Takes at least 90 seconds to fully load,
using 100% cpu the whole while.  Other browsers (IE and NS) take 40 seconds, so
it's a slow page to begin with, but they don't use 100% cpu.

STEPS TO REPRODUCE: Load http://www.voodooextreme.com

ACTUAL RESULTS:  Extremely slow load time, using 100% CPU

EXPECTED RESULTS: Load time on par with other browsers, and definitely shouldn't
pin the CPU.

VERSION TESTED: Win32 1999-12-03-02

The cause of this bug may not be the same as what is described in the above
comments, but the symptoms are, so I thought it should be filed here rather than
as a separate bug.
No, please don't add unrelated bugs to this report. This bug has been narrowed
down to font issues. Your added bug hasn't been narrowed down to font issues,
so it could well be a different issue. If you put this on my list, it may get
ignored for a while (I'm going on a 6-week sabbatical starting Dec 18). Please
create a separate bug report and assign to rickg@netscape.com so that it has
some chance of being addressed.
Summary: page takes 60 seconds to load → page takes 60 seconds to load due to Unix font loading
skoll@pacbell.net, please file that as a separate bug, as erik said.  This bug
is well understood, and is Unix-specific.

In general, if you're not sure if something's a duplicate, file a separate bug
and mention the possibly-related bug.  Otherwise, bugs become too difficult to
understand because of unrelated comments.
Yes yes.  My apologies.  It is now filed as bug 20485.  I make very careful
bugzilla queries to avoid filing duplicate bugs, and to add relevant info to
existing bugs, but this time my search had led me astray.

Changing the summary, like you did, should help prevent it from happening again.
Keywords: perf
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.
Moving all of my M15s to M16. Please add comments if you disagree.
Target Milestone: M15 → M16
Whiteboard: [Perf]
At some point, I hope to look into the following. Erik.

Subject: bigfont optimization
Date: Mon, 7 Feb 2000 16:41:33 +0100 (MET)
From: Bruno Haible <haible@ilog.fr>
To: patch@XFree86.Org
CC: fonts@XFree86.Org

Here is a new version of the bigfont optimization.

Remember that big fonts suffer from the following: All clients that have
opened a font can access the complete glyph metrics array (the XFontStruct
member 'per_char') directly, without going through a macro. Moreover these
glyph metrics are ink metrics, i.e. are not redundant even for a fixed-width
font. For a Unicode font, the size of this array is up to 768 KB. For
the Unicode fonts already present in 3.9.17, the size varies between 120 KB
and 150 KB.

The first version of this patch, months ago, optimized only the case of
local clients, by use of shared memory, and left the remote clients
unoptimized.

This version here also optimizes the non-local clients: the glyph metrics
are transmitted over the wire in a compressed format, which reduces the
size of the transmitted data by nearly a factor of 6 for large fonts,
and still by a factor of 2 for small 8-bit fonts. The compression is fast
(O(N) where N is the size of the uncompressed data).

Care has been taken for interoperability with older/other X11 vesions:
A client with an older libX11 obtains the uncompressed data via the socket,
unchanged. Newer clients with an older X server will notice the X server
doesn't understand the XF86BIGFONT extension and will fall back on the
old mechanism.

I've been running this patch for 4 weeks now, without problems. But in the
- unexpected - case that the extension causes problems to someone, it can
be disabled by setting the XF86BIGFONT_DISABLE variable to 1.

                                Bruno


New files:
xc/include/extensions/xf86bigfstr.h
xc/include/extensions/xf86bigfont.h
xc/programs/Xserver/Xext/xf86bigfont.c

Modified files:
xc/config/cf/xfree86.cf
xc/include/extensions/Imakefile
xc/lib/X11/Font.c
xc/lib/X11/Imakefile
xc/lib/X11/Xlibint.h
xc/programs/Xserver/Xext/Imakefile
xc/programs/Xserver/dix/dixfonts.c
xc/programs/Xserver/hw/xfree86/common/xf86Events.c
xc/programs/Xserver/mi/miinitext.c
From: Bruno Haible <haible@ilog.fr>

I don't think the bug you mentioned [1] will profit a lot from the
extension:

The user saw the X server busy for 60 seconds. If only one font is involved,
then gunzipping the file and rendering the truetype font is certainly much
more costly than filling 768 KB of memory and piping it to a client. If
more than one font is accessed -- you can "see" which fonts have been
accessed by the X server by simply doing an "ls -lrtu
/usr/X11R6/lib/X11/fonts/..." after the operation -- then the way to solve
the problem is to touch less fonts, i.e. to give more precise wildcards
in the XLFD.

Bruno

[1] http://bugzilla.mozilla.org/show_bug.cgi?id=14961
I think that, when this happens, it's generally a case where the character is
not in any of the available fonts, so one must check all the fonts with a
character encoding that could contain the character.  (However, are you sure you
never check fonts that are in an encoding that couldn't have the character?)
From: Juliusz Chroboczek <jec@dcs.ed.ac.uk>
To: fonts@XFree86.Org

EvdP>   http://bugzilla.mozilla.org/show_bug.cgi?id=14961

No, Erik.  The problem you see here is different.

The X protocol specifies that font metrics should be made available to
the server at font open time.  This means that the TrueType backend
needs to rasterise all glyphs at font open time just to determine the
metrics.

There is currently only one workaround: the TrueType backend optimises
the special case of charcell fonts (this was implemented with CJK
users in mind).  I suggest your users avoid humonguous proportional
fonts such as Cyberbit.

Sincerely,

                                        J.
> (However, are you sure you
> never check fonts that are in an encoding that couldn't have the character?)

The code looks at the encodings indicated by XListFonts(). It will not actually
*load* any font that is known not to contain the right glyph. However, for
*-iso10646-1 fonts, it is impossible to tell which glyphs are contained without
loading the font. Maybe I should make sure that *-iso10646-1 fonts are used as
a last resort (i.e. try them last, after all the other encodings). See the
TryFamily() function.
*** Bug 28772 has been marked as a duplicate of this bug. ***
http://www.linux.com/ runs quite slow due to font querying on Unix.
Timing performed with a 3/2 morning cvs pull compiled with
--disable-debug --enable-optimize --enable-x11-shm.  The test machine
was a Sun Ultra-10 (440Mhz/afb) running Solaris 2.7.  viewer was
started with "about:blank", then "http://www.linux.com/" typed into
the url entry box.

                start   end     elapsed
viewer           0:02    0:03   0:01
Xsun            96:57   97:26   0:29
wall time                       0:36

Examining an xscope log of a similar session, I see three groups
of continuous ListFontsWithInfo calls amounting for about 28 seconds
worth of load time.

start load ~ 29.56s
ListFontsWithInfo       30.51-31.42     ~15 calls
ListFontsWithInfo       31.72-57.15     ~180 calls
ListFontsWithInfo       58.25-59.97     ~12 calls
finish load ~ 67.46s

I'm running with the default font path for solaris (see below).
The output of "xlsfonts" will be attached to this bug.  xscope
log available on request (1.2 Mb).

  /usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/open
win/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11
/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi
/


    
    

    
  
Created new bug 30160 for XListFontsWithInfo problem. That call is far too
expensive and must be removed from Mozilla.

    
    

    
  
How often is this problem encountered? I'm leaving the target as M16 for now,
though I *really* don't know what to do about this, other than some hacks...

    
    

    
  
Just for fun i loaded the "problem" URL's in Netscape Communicator 4.7. Cached
files were deleted and Netscape 4.7 started afresh.
Got these times on complete loads:
http://www.fas.harvard.edu/~dbaron/links/Internet 10 sec.
http://www.fas.harvard.edu/~dbaron/css/test/results 11 sec.

System: P120 running Linux RH6. 36k modem connection. (With a 56k modem).
Located in Norway.

    
    

    
  
Same configuration, testing with Mozilla nightly build ID 2000-040109
http://www.fas.harvard.edu/~dbaron/css/test/results 25 sec.


    
    

    
  
I don't think it's a good idea to put hacks into Mozilla to try to work around
the problem with large TrueType fonts taking a long time to load. We will
probably have to tell users to avoid installing such large fonts, or to get a
faster TrueType server. Also, I don't want to treat *-iso10646-1 fonts specially
since there are some small ones that load fast and look nice in newer versions
of XFree86 (based on Adobe's original contribution, etc). Marking WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX

    
    

    
  
Marking verified won't fix per last comments.

Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: