One of the largest performance bottlenecks in Element.getAttribute (and I
suspect a bunch of other webidl bindings as well) is copying (often very
small) SpiderMonkey strings into heap allocated DOMStrings. It doesn't seem
practical to always use JS strings as they don't use UTF-8 and it would
requ
> One of the largest performance bottlenecks in Element.getAttribute (and I
> suspect a bunch of other webidl bindings as well) is copying (often very
> small) SpiderMonkey strings into heap allocated DOMStrings.
Alan Jeffrey has been investigating issues around string copying as
well. Have you ch
On Tue, Dec 1, 2015 at 5:48 PM, Jack Moffitt wrote:
> > One of the largest performance bottlenecks in Element.getAttribute (and I
> > suspect a bunch of other webidl bindings as well) is copying (often very
> > small) SpiderMonkey strings into heap allocated DOMStrings.
>
> Alan Jeffrey has been
Yes, I've done some experiments with this. Inlining small strings didn't
help as much as I'd hoped, I suspect because they're being converted to
Strings or JSStrings a lot. I'm still in the middle of experimenting, I'm
hoping to write up soon. The code is at
https://github.com/asajeffrey/servo/tree
On 02/12/15 02:39, Nick Fitzgerald wrote:
I've created a crate[0] that provides a mostly drop-in replacement of
std::string::String but with inline storage for small strings to avoid heap
allocation.
[0]https://github.com/fitzgen/inlinable_string
There’s also [1], already in used in Servo in s
5 matches
Mail list logo
