.

With this patch, the "dataset" case shows "270,904" on http://jsperf.com/data-dataset/2. That's compared to "212,353" without the patch and "260,409" for Chrome.

Oh, and on http://jsperf.com/data-dataset we end up at "894,407" with patch compared to "689,389" without.

With this, I get "413,135" on http://jsperf.com/data-dataset/2 and "1,235,610" on http://jsperf.com/data-dataset That's about as good as we can do until we have WebIDL for HTMLElement. At that point I fully expect even better numbers.

Changed nsDOMStringMapSH::PreCreate to be more like other ::PreCreates

Comment on attachment 671963 [details] [diff] [review] wrappercache The comment about nsIDOMMutationObserver should talk about nsIDOMDOMStringMap, right? r=me with that.

Yes.

Comment on attachment 671947 [details] [diff] [review] Patch on top of that that adds a custom quickstub >+nsDOMStringMap* >+nsGenericHTMLElement::Dataset() > { > nsDOMSlots *slots = DOMSlots(); > > if (!slots->mDataset) { > // mDataset is a weak reference so assignment will not AddRef. > // AddRef is called before assigning to out parameter. > slots->mDataset = new nsDOMStringMap(this); > } > >- NS_ADDREF(*aDataset = slots->mDataset); >+ return slots->mDataset; >+} I think we want to make this to return already_AddRefed. It is scary is slots->mDataset points to an object which has refcount 0. >+nsGenericHTMLElement::GetDataset(nsIDOMDOMStringMap** aDataset) >+{ >+ NS_ADDREF(*aDataset = Dataset()); then this would be *aDataset = Dataset().get(); >+ 'nsIDOMHTMLElement_GetDataset': { >+ 'thisType' : 'nsGenericHTMLElement', >+ 'code': ' nsDOMStringMap *result = self->Dataset();', And this could be then nsRefPtr<nsDOMStringMap> result = self->Dataset();

https://hg.mozilla.org/mozilla-central/rev/62f61773ad45 https://hg.mozilla.org/mozilla-central/rev/cf65ae722cbb