Closed
Bug 843936
Opened 11 years ago
Closed 2 years ago
[perf] reading element.offsetHeight and element.offsetWidth very extremely slow
Categories
(Core :: Web Painting, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mayhemer, Unassigned)
References
()
Details
(Keywords: perf)
This was also discovered while scrolling simile timeline (as bug 843935). I am solving this issue by caching the value which makes scrolling visibly faster. To compare, in Chrome (dev) moving the timeline is absolutely smooth.
Comment 1•11 years ago
|
||
Are you interleaving these gets with style changes?
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #1) > Are you interleaving these gets with style changes? No idea, the timeline code is complex and I am not an author. However, there is significant impact of caching the offset* values. The timeline has a more smooth feeling and is objectively faster. Unfortunately, only a bit faster... Not cached code, timing of [1]: Calls % Own Time Time Average Min Max 234 94.92% 3020.069ms 3020.646ms 12.909ms 0.009ms 36.798ms Cached code of [1]: Calls % Own Time Time Average Min Max 204 0.97% 1.314ms 1.855ms 0.009ms 0.008ms 0.016ms [1] http://code.google.com/p/simile-widgets/source/browse/timeline/trunk/src/webapp/api/scripts/band.js#351 PS: In general, using chrome and their profiler, they spend 95% of JS time at idle... We use 100% of a CPU core time (with either the "caching patch" or w/o). Chrome uses around 60% (rough est, since I'm on an 8 core machine).
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Comment 3•2 years ago
|
||
Last comment almost a decade ago, a lot has changed since then. Testcase no longer seems accessible. If there is still a problem here we'll need updated STR and a testcase.
Severity: major → S3
Status: NEW → RESOLVED
Closed: 2 years ago
Priority: -- → P3
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•