Works for me 2003090505 Linux after stalling for 45 seconds. I suspect this is due to the 1.66 megabyte JS file it links to at http://www.joki-foto.de/fotoshop/search.js JS console gives no errors.
WFM Gecko/20030902 Firebird/0.6.1+. Does not hang, it just takes long time to load the page.
Not likely to be a JS engine bug per se... over to General until we have a minimal testcase that shows the problem. If this is just a perf issue, perhaps a profile of the pageload is in order?
Assignee: rogerl → general
QA Contact: pschwartau → general
Does it just create the array, or does it create DOM nodes from it? I would assume the latter... If you have a functioning testcase that you can zip up (due to the size this may be needed) and attach here that shows the pageload issue, please go for it.
Well, how interesting. This _is_ a JS engine issue after all. Though I do wonder why the fix for bug 13350 is not kicking in. The profile shows: Total hit count: 10809 Count %Total Function Name 10666 98.7 GetChar 27 0.2 FindCharInReadable 7 0.1 nsTextFragment::SetBidiFlag 6 0.1 memmove Everything else is below the 0.1% level. Of the 10666 hits in GetChar, we have (more or less; the sum will be greater than 10666 because a few of those hits are actually under js_AtomizeChars, not GetChar): 572 coming from js_GetToken 174 coming from js_PeekToken 131 coming from UnaryExpr 1189 coming from js_MatchToken 8751 coming from UnaryExpr It looks like the only callstack that ends up in UnaryExpr is: UnaryExpr MulExpr AddExpr ShiftExpr RelExpr EqExpr BitAndExpr BitXorExpr BitOrExpr AndExpr OrExpr CondExpr AssignExpr 10704 of the total 10809 hits are under AssignExpr. Moving on up, it looks like most of that stuff is under AssignExpr Variables Statements js_CompileTokenStream (10707 of the total hits). That probably explains why the DOM can't interrupt this mess -- this is an atomic compilation operation....
Assignee: general → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang, qawanted → perf
OS: Windows XP → All
QA Contact: general → pschwartau
Hardware: PC → All
The issue seems to be that the script is all a single line. After running: perl -pi -e 's/new Array/\nnew Array/g;' testcase.htm the file loads in Mozilla in about five seconds (still freeze up for those five seconds, though).
Big fun -- thanks for the profile, bz. (No one should put everything on one line! That's just wrong ;-) /be
Assignee: general → brendan
Created attachment 142781 [details] [diff] [review] proposed fix (apply this) Reviewers: diff -w version coming right up. /be
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.7beta
Comment on attachment 142783 [details] [diff] [review] diff -w version of last patch (review this) I like pathology. r=shaver
Attachment #142783 - Flags: review?(shaver) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
OK, with that patch 6 pageloads give me: Total hit count: 1087 Count %Total Function Name 171 15.7 FindCharInReadable 78 7.2 GetChar 45 4.1 nsTextFragment::SetBidiFlag 41 3.8 memcpy 31 2.9 FindInReadable 30 2.8 memmove 28 2.6 js_GetToken 21 1.9 js_MatchToken 20 1.8 js_SearchScope So GetChar is still up there, but it's much better now... (like nearly 4 orders of magnitude better). I filed bug 236272 on looking into making the the code that's calling FindCharInReadable (CTextToken::ConsumeUntil) a litte faster.
You need to log in before you can comment on or make changes to this bug.