string-fasta is 10x slower than BL-Ion because of this. Need optimized stubs for (in priority order): IteratorNext IteratorMore IteratorNew IteratorClose

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.

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.