Bug 96244 – Add AtomicString::number() and use it

• Component: Web Template Framework
• Status: NEW

[Patrick R. Gansterer]

Add AtomicString::number() and use it

[Patrick R. Gansterer]

Created attachment 163065 [details]
Patch

[Alexey Proskuryakov]

I'm wondering how much sense it makes for attribute values to be atomic strings. I know that this is how it's been for a long time, but anyway.

[Benjamin Poulain]

Comment on attachment 163065 [details]
Patch

This is great, it should avoid creating StringImpl temporarily.

r- because I would like some WebKit API tests for the change.
It would be nice to have benchmark numbers in the ChangeLog. A microbenchmark should be able to point out changes visible from JavaScript.


If you have time, there is a nice improvement possible for this AtomicString::number() - (for a separate patch).
Currently, you use string hash() on the converted number. You could design a hash() function homomorphic to the hash for string(). Depending on the operations, the homomorphic hash() could be faster (or slower...) than string hash on the converted value.


(In reply to comment #2)
> I'm wondering how much sense it makes for attribute values to be atomic strings. I know that this is how it's been for a long time, but anyway.

This is a valid point.

I am in favor of going forward with this patch. Changing the type of the values is a important change. This tiny patch reduces nicely the need for extraneous StringImpl without adding any complexity to the codebase.

[Benjamin Poulain]

Do you have any plan to update this patch? If not, I might take the bug.