Closed Bug 362997 Opened 18 years ago Closed 18 years ago

trunk is unacceptably slow loading Japanese sites

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED DUPLICATE of bug 357637

People

(Reporter: dbaron, Assigned: masayuki)

References

(
URL
)

Details

Attachments

(1 file)

jprof profile
381.83 KB, text/html; charset=UTF-8
Details 
Performance loading  http://www.w3.org/2006/11/W3C10/ja/ has become unacceptably slow on the trunk on Linux.  This is a regression between 2006-11-20-04-trunk and 2006-11-21-04-trunk .  This performance is slow enough that it blocks testing, and I think the offending checkin should be backed out if it cannot be fixed promptly.  The most likely cause seems to be bug 352174.

Steps to reproduce:
 * load http://www.w3.org/2006/11/W3C10/ja/

Actual results in 2006-11-21-04-trunk and a debug build from yesterday:
 * page takes about 55 seconds to load, and the browser is locked up most of that time
 * page takes about 8 seconds to repaint if the window is covered by another one and then exposed again
 * tons of:

(Gecko:4143): Pango-WARNING **: Error loading GPOS table 4097

    are printed to the console.

Expected results (as observed in 2006-11-20-04-trunk):
 * page loads in 2-3 seconds

The problem also seems to be present on http://www.tokyometro.jp/index.html

I'm using Fedora Core 6.
Attachment #247717 - Attachment is patch: false
Attachment #247717 - Attachment mime type: text/plain → text/html; charset=UTF-8
Oshima-san and taken-san:

Can you reproduce this slow rendering?
Do you have the japanese font package (fonts-japanese.noarch) installed?  I was seeing performance problems with missing fonts.

Yes, I have fonts-japanese (and pretty much all the other vector fonts that come with Fedora) installed.
I see what happens.

the computed value of the paragraph is "font-family: Gill Sans MT,Gill Sans,GillSans,Verdana,Lucida Grande,Lucida Sans,Lucida Sans Unicode,sans-serif;" on  http://www.w3.org/2006/11/W3C10/ja/ .

Do you have "Gill Sans MT"? If you don't have this font, the font name resolver doesn't work fine by bug 362048.

Note that the current Itemizing rendering is too slow, but maybe it will be fixed by the new text frame of roc.
(In reply to comment #5)
> Do you have "Gill Sans MT"? If you don't have this font, the font name resolver
> doesn't work fine by bug 362048.

No, I don't have the font.
Depends on: 362048
The patch in bug 362048 doesn't help, though.  (I just applied the one change at the beginning of gfxPlatformGtk::ResolveFontName to initialize aAborted to PR_FALSE.)
No longer depends on: 362048
O.K. I think that this bug is an issue of Itemizing function performance. Now, the gfxTextRuns are cached. I think that if we cache the itemized result, we can improve the performance.

I don't want to back-out the font-name resolver. Because the patch is the base of my other works...
(In reply to comment #2)
> Oshima-san and taken-san:
> 
> Can you reproduce this slow rendering?
 
No I can't reproduce.
I don't think rendering of the URL is slower than
other Japanese pages on yesterday's trunk build.
I don't apply any patch.

Thanks.

I'll attach a patch that should be used until bug 333659.
I have a similar problem only with my own build, not with distributed nightly build.  My own build takes very long to load(or render) Japanese page.  But nightly build at ftp.mozilla.org has no problem.   What's my problem?  I build on Gentoo and my .mozconfig is

ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize="-O2 -fomit-frame-pointer"
#ac_add_options --without-system-nspr
#ac_add_options --without-system-zlib
#ac_add_options --without-system-jpeg
#ac_add_options --without-system-png
#ac_add_options --without-system-mng
mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite

If the nightly build is seamonkey, it may not be non-cairo build.
I create a draft for the patch. But I cannot test now.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3409
Assignee: nobody → masayuki
Sorry, the previous patch is wrong.
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3410
Status: NEW → ASSIGNED
Is this a dupe of bug 357637?
(In reply to comment #18)
> Is this a dupe of bug 357637?
> 

Oh, you're right. I forget the bug, sorry.

*** This bug has been marked as a duplicate of 357637 ***
No longer blocks: 352174
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: