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)

defect

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).
Blocks: 117611
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
No longer blocks: 558451
Depends on: 558451
Priority: P1 → P3
Target Milestone: mozilla2.0b2 → mozilla2.0
Easier to do this after bug 558451 (fixed now) and cleanup (bug 593129) too.

/be
Depends on: 593129
No longer depends on: 558451
I want to do this still, but no way is it a moz2/fx4 blocker.

/be
Target Milestone: mozilla2.0 → Future
Target Milestone: Future → ---
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?
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
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?
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?
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.

Attachment

General

Created:
Updated:
Size: