Closed
Bug 367425
Opened 18 years ago
Closed 13 years ago
Javascript: Object construction time O(n^2) when getter closures used (Part II)
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bc, Assigned: brendan)
References
Details
(Keywords: perf)
Attachments
(2 files)
forked from bug 335700 comment 34. Using the testcase js1_5/Object/regress-335700.js <attachment 251751 [details]> modified to change the range from 0 to 40,000 I see the following in the js shell on windows (before patch, after patch): Count Before After 0 0 0 4000 656 94 8000 5250 360 12000 14047 1234 16000 27312 3047 20000 46594 6531 24000 65719 11188 28000 88110 17234 32000 119734 24860 36000 147984 34000 40000 187610 42282 This still shows quadratic growth at least for the smaller ranges (0 to 25,000).
Reporter | ||
Comment 1•18 years ago
|
||
Assignee | ||
Comment 2•14 years ago
|
||
We badly need to despecialize. I will try patching this as a prerequisite for bug 558451 (it has a big queue, I could do it there, and may yet if it looks like the shorter path). /be
Assignee: general → brendan
Blocks: 558451
Status: NEW → ASSIGNED
OS: Windows XP → All
Priority: -- → P1
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.3b2
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Updated•14 years ago
|
Priority: P1 → P3
Target Milestone: mozilla2.0b2 → mozilla2.0
Assignee | ||
Comment 3•14 years ago
|
||
Easier to do this after bug 558451 (fixed now) and cleanup (bug 593129) too. /be
Assignee | ||
Comment 4•13 years ago
|
||
I want to do this still, but no way is it a moz2/fx4 blocker. /be
Target Milestone: mozilla2.0 → Future
Assignee | ||
Updated•13 years ago
|
Target Milestone: Future → ---
Comment 5•13 years ago
|
||
This test has since been turned off (since it does this O(n^2) measurement that tends to be flakey and get disabled), but when I turn it on and run it, its definitely linear up to 40K. Can this be resolved fixed?
Assignee | ||
Comment 6•13 years ago
|
||
Wow, great. How'd that happen? There should be a fresh shape for each instance with a getter and setter assigned from fresh closures per instance. /be
Comment 7•13 years ago
|
||
I guess there's a chance my numbers didn't get high enough to express their quadratitude (40000 for ObjectWithGetter only got to 42ms). Btw, since Waldo wiped out the old getter syntax, I had to freshen up the test with Object.defineProperty; perhaps that changed things?
Comment 8•13 years ago
|
||
I just played with bigger numbers and still stays pretty darn linear. Another idea of how it got fixed is some of this "convert to hash table earlier" work that I saw from a distance a few months ago?
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•