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)
Core
JavaScript Engine
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
Assignee | ||
Updated•25 years ago
|
Assignee | ||
Comment 1•25 years ago
|
||
Moving out, but may fix at the same time as I fix bug 56940.
/be
Keywords: mozilla0.8 → mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
Assignee | ||
Updated•24 years ago
|
Keywords: mozilla0.9 → mozilla0.9.1
Comment 3•24 years ago
|
||
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.
Assignee | ||
Comment 4•24 years ago
|
||
Load-balancing.
/be
Keywords: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Comment 5•24 years ago
|
||
Not clear that this matters much to real-world JS. Anyone have data?
/be
Keywords: mozilla0.9.2 → mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla0.9.5
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.6
Assignee | ||
Comment 7•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•