Closed Bug 839303 Opened 10 years ago Closed 10 years ago

BaselineCompiler: Implement optimized iterator stubs.

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: djvj, Assigned: bhackett1024)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

string-fasta is 10x slower than BL-Ion because of this.

Need optimized stubs for (in priority order):
IteratorNext
IteratorMore
IteratorNew
IteratorClose
Assignee: general → bhackett1024
Attached patch next/more stubsSplinter Review
This adds stubs for IteratorNext and IteratorMore, which are hit about 23k times each on SS.  Constructing and closing iterators inline is considerably more complicated and needs some refactoring of the related Ion methods to avoid duplicating lots of code.  These other two are hit about 6k times each, so relatively small fish to fry.
Attachment #713137 - Flags: review?(kvijayan)
Comment on attachment 713137 [details] [diff] [review]
next/more stubs

Review of attachment 713137 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.  With IteratorNew, we could help it out a little bit.  Currently the main slowdown is being forced to do a stack walk to get the script, so we can get the PC, so we can obtain the uint8_t flags to pass to ValueToIterator.  We can stick the flags as a field on the stub.

Actually, all stubs have an unused 16-bits or so sitting silently in-between the kind_ and stubCode_ fields.  We could just make that into a generic 'uint16_t extra_' field that's usable by subclasses to store some kind-specific info.

But yeah, it's not a big deal ATM.. bigger fish to fry.
Attachment #713137 - Flags: review?(kvijayan) → review+
https://hg.mozilla.org/projects/ionmonkey/rev/62cd1a858417
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.