Closed Bug 307251 Opened 19 years ago Closed 19 years ago

After running for a few days, app slows to a crawl (leak?)

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Camino1.0

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

References

Details

(Keywords: perf, qawanted, Whiteboard: needinfo) 

after running 2005083004 branch (and other recent builds) for a few days, the
app slows to a crawl loading larger pages like http://www.engadget.com or
http://www.gizmodo.com. 

If you sample it, you get a lot of time spent in text measuring. However, if you
Shark it, you see 90% of the sample is spent in OS VM code handling swapping.
Quitting camino and relaunching immediately restores said websites to almost
instantaeous pageloads.

I suspect we're leaking something non-trivial over time with each window.
this is a showstopper.
Target Milestone: --- → Camino0.9
Any data from top? Also, this could be an OS bug.
I think this is the same thing as bug 301404, based on your comment about
sampling, but I'll mark it dependent for now.
Depends on: 301404
Bug 306742 may also be related.
i doubt it's an OS bug, i only see this with recent builds.
Target Milestone: Camino0.9 → Camino1.0
In bug 313284 comment 6, I said:
> Considering all of the unsubstantiated "starts fast, gets slow" reports, it
> might be a good start to try quantifying this.  Some QA-minded person could do
> a pageload set, wait for it to finish, note the results, rinse, and repeat 
> over a period of time to see if we have a measurable decay.

...and if you find measurable deterioration after the app's been busy for a while, compare samples to see what's changing between a freshly-launched app and a retarded one, and take a look at CPU and VM statistics in top.

...and since there's disagreement about whether or not this is an OS bug, maybe see if it's also reproducible under Panther.
Keywords: qawanted
*** Bug 313284 has been marked as a duplicate of this bug. ***
Keywords: perf
Whiteboard: needinfo
Well, unfortunately Camino just quit on me for the first time in forever :-(  Camino'd been running for 55 hours, according to Talkback.  

I hadn't tried to visit Mike's sites in comment 0 in the last 6 hours, but the last time I checked, they didn't seem particularly slow.  Certainly nothing I'd describe as "slows to a crawl".  Slower than on first launch, maybe, but within the margin of error for network connection fluctuation and slow loading of the JS (I noticed that requests for ad-site JS files seemed to be very slow every time I loaded the pages) IMO.

2005102704 (v1.0a1+), 10.3.9
OK, Camino has been running for over 48 hours now since the last crash.

On subsequent tests, cache was emptied to ensure the pages were not still in cache.  Time measured from hitting return with URL typed until progress bar vanishes; all times ± 1 second for finger-sync.

ca. 20 minutes into use:
engadget - 30 sec
gizmodo - 23 sec

ca. 24 hours into use:
engadget - 14 sec (including some waiting for external (ad) js to arrive)
gizmodo - 14 sec (including some waiting for external (ad) js to arrive)

ca. 48 hours into use:
engadget: 9 sec
gizmodo: 14 sec

So on 10.3.9 with Camino having been open for 48+ hours, I don't see anything that seems like a slowdown.  I'd call it pretty even given I know my connection throughput tends to fluctuate....

Do I need to keep running for a few more days?  Are there any other "tests" I should run/specific things I should do?  Or does it seem like it's really 10.4-only?
If this is really bug 301404, it's 10.4.0 - 10.4.2 only.
Thanks, Smokey, that's very useful.  Has anyone experienced different results under 10.4.2?  10.4.3?
WFM unless proven otherwise (please test on 10.4.3)
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
*** Bug 310289 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.