If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

100% CPU load on certain URL

RESOLVED WORKSFORME

Status

SeaMonkey
General
RESOLVED WORKSFORME
14 years ago
8 years ago

People

(Reporter: Jean Jano, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040120 Firebird/0.8.0+

100% CPU load on certain URL: http://www.ag.ru/?gallery?12026?76206

Reproducible: Always
Steps to Reproduce:
1. get http://www.ag.ru/?gallery?12026?76206
2.
3.

Comment 1

14 years ago
Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040120 Firebird/0.7+. 100% CPU while the page is displayed, compared to
20% for IE. No hang though.

Not Firebird-specific, moving to Browser - General.
Assignee: blake → general
Component: General → Browser-General
Product: Firebird → Browser
QA Contact: general
Version: unspecified → Trunk

Comment 2

14 years ago
sluggish perfomance due to JavaScript, but that would be too general...
Assignee: general → general
Component: Browser-General → JavaScript Engine
QA Contact: general → pschwartau

Comment 3

13 years ago
confirming 100% CPU while displaying the page with Mozilla 2004062308 & WinXP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Someone jprof this.

Please use Browser-General until you can prove JS is to blame.

/be
Component: JavaScript Engine → Browser-General
With a current Linux build I see us taking about 10-15% of CPU (on a P3-733). 
Mostly animating gifs (hence painting) and doing some JS off a timeout.

So in short, I can't reproduce this bug.

Comment 6

13 years ago
This is another example where even Firefox1.0PR goes down and utilises 100% CPU
(but not crashing, visiting another URL solves the issue):

http://free.grisoft.com/freeweb.php

It really seems to be JS, I suspect the ticker to be the source of the
performance-hole.

Tried on Firefox 1.0 PR/WindowsXP and on Firefox 0.9.3/BeOS on a different system.
> This is another example where even Firefox1.0PR goes down

The rendering engine in Firefox1.0PR is 6 months old.  In particular, it's about
3 months older than the rendering engine I was using in comment 5.  Please do
test a current trunk build; there's been a lot of work in the last 6 months on
DHTML performance.

If you still see the problem, please file a separate bug on it (and cc me).
Product: Browser → Seamonkey
http://free.grisoft.com/freeweb.php and
http://www.ag.ru/?gallery?12026?76206
both WFM - no 100% cpu for FF 1.0.4 or for Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a

Please reopen if you still see the problem on a current version of the suite.

Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Comment 9

11 years ago
(In reply to comment #8)
> http://free.grisoft.com/freeweb.php
Using Firefox 1.5.0.4 on WinXP, I still get 60%-80% CPU-usage, supposedly due to the Javascript-scroller.

> http://www.ag.ru/?gallery?12026?76206
down to ~30% but goes up to 60% if you hover the mouse over the image.
hmm, you're absolutely right**.  I must have had a javascript blocker when I attempted the first url - duh.  But I have no doubt though these two issues have open bugs in their respective core components.  Feel free to dup this bug to one of them.

** tested on:

ff 1.5.0.4 and 
FF trunk Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060625 SeaMonkey/1.5a

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