Closed Bug 61897 Opened 25 years ago Closed 24 years ago

Space pigs: String.prototype.charAt and str_getProperty for s[i]

Categories

(Core :: JavaScript Engine, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: brendan, Assigned: brendan)

References

Details

(Keywords: js1.5)

JS users should not be writing too many char-by-char loops over strings (they should use regexps instead!) but if any are, then the engine will malloc 4-byte string vectors (two chars, the indexed char and NUL) to beat the band. Ideally, we'd make a JSString that shared space with its super-string until the latter needed to be finalized, then copied (if the substring was still alive too, of course). See bug 54743 for some results from kandrot. /be
Status: NEW → ASSIGNED
Keywords: js1.5, mozilla0.8
Target Milestone: --- → mozilla0.8
Moving out, but may fix at the same time as I fix bug 56940. /be
Keywords: mozilla0.8mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
Slipping.
Target Milestone: mozilla0.9 → mozilla0.9.1
Keywords: mozilla0.9mozilla0.9.1
Putting comments here since bug #54742 is closed. The speed of JS appears to be much faster now! The looping and math routines are faster than 4.7.6 (2x - 3x), under Linux. The test for credit card validation is still half the speed of 4.7.6, due to the charAt code that is a part of this bug. There is a sample js called Luhn in the original bug that demonstrates this problem. If there is any need to further track down this problem, let me know, and I will add the scripts/profiles to this bug.
Load-balancing. /be
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Not clear that this matters much to real-world JS. Anyone have data? /be
Keywords: mozilla0.9.2mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Fixed by bug 56940's patches. /be
Depends on: 56940
Target Milestone: mozilla0.9.7 → mozilla0.9.6
I claim this is fixed by the fix for bug 56940. The only wrinkle left, which I think should result in a new bug, is that if you repeated fetch s[i] for a given value of s and i, you'll create a new dependent string for each access. Note well that this is no worse than what happens with the ECMA-conformant charAt method, used instead of indexing (s.charAt(i)). We might be able to avoid that without requiring a real property and slot to be allocated for each such i, perhaps by atomizing the alphabet. But I'm not going to go there without compelling, real-world examples that need it. Given the non-ECMA status of s[i], I don't expect such examples to exist. /be
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.