Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-05 Thread Alan Jeffrey
Another shot at an improved DOMString representation. This one uses one of 3 representations: either a String, an inlined string (for < 16 bytes) or an interned string: https://github.com/asajeffrey/servo/tree/domstring-use-atom-or-inlined-string I did lots of hoop-jumping to get it to fit in the

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-02 Thread Boris Zbarsky
On 12/2/15 4:23 PM, Andrew McCreight wrote: For what it is worth, Gecko uses a single-entry per-zone cache for converting the result of JS strings to DOM strings in getAttribute (I think) No, that's the other direction: DOM strings to JS strings. -Boris

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-02 Thread Alan Jeffrey
Yes, this is on my list of things to think about. On Wed, Dec 2, 2015 at 3:23 PM, Andrew McCreight wrote: > For what it is worth, Gecko uses a single-entry per-zone cache for > converting the result of JS strings to DOM strings in getAttribute (I > think). bz added this in bug 773520, and it has

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-02 Thread Andrew McCreight
For what it is worth, Gecko uses a single-entry per-zone cache for converting the result of JS strings to DOM strings in getAttribute (I think). bz added this in bug 773520, and it has had a few refinements since then. Maybe some kind of caching would help Servo, too. Andrew On Wed, Dec 2, 2015 a

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-02 Thread Alan Jeffrey
Well, I tried eliminating the buffering, but I still didn't get any perf benefit, if anything there was a degrade. Sigh. https://github.com/asajeffrey/servo/commit/1533238eb822688572a04d5bd6eb8ac88297 On Wed, Dec 2, 2015 at 10:49 AM, Nick Fitzgerald wrote: > And there is also ArrayString[0]

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-02 Thread Nick Fitzgerald
And there is also ArrayString[0] from the arrayvec crate[1]. I was considering reusing this and getting rid of the fixed size `InlineString` I rolled myself as ArrayString is almost identical. [0] http://bluss.github.io/arrayvec/doc/arrayvec/struct.ArrayString.html [1] https://crates.io/crates/arr

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-01 Thread Simon Sapin
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

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-01 Thread Alan Jeffrey
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

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-01 Thread Nick Fitzgerald
​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

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-01 Thread Jack Moffitt
> 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

[dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

2015-12-01 Thread Nick Fitzgerald
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