Issue #15331 has been updated by duerst (Martin Drst).


nobu (Nobuyoshi Nakada) wrote:
> Isn't 1% a measurement error?
> Does it always occur constantly?

If a 1% improvement is consistently reproducible, then it's worth reconsidering.

alanwu (Alan Wu) wrote:
> I proposed this change because every attribute access in Active Record goes through a hash lookup.
> When we profile our app in production, Active Record attribute access shows up as a clear hot spot.

That doesn't come as a surprise to me.

> When I used this patch to run response time benchmark against https://github.com/codetriage/codetriage,
> there was a 1% improvement. A 1% improvement would be translate to a great deal of cost savings for us in production.

Can you give more information? What 'response time benchmark' did you use (I didn't find any such benchmark in codetriage, but I didn't look very hard and am not familiar with that application)? Did you try other benchmarks, or can you try them?

> I'm disappointed that the patch doesn't provide enough speed-up to justify the maintenance burden,
> but I thank you both for your time.

I don't think we say that 1% isn't enough. If it's reproducible, it's very easily worth it. But if we can't reproduce the speedup, it's difficult for us to include your code.

----------------------------------------
Feature #15331: [PATCH] Faster hashing for short string literals
https://bugs.ruby-lang.org/issues/15331#change-76840

* Author: alanwu (Alan Wu)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
## Background

It's common for applications to use string literals as hash keys, especially
for applications that work with YAML or JSON:

```
paylod['name']
```

At the moment (r65895), hash lookups using a string key is about 30% slower
than using a symbol key.

## Proposal

We memoize the hash code for short fstrings. There is extra, currently unused
space at the end of the RString struct we can use to store the hash code.
The unique nature of fstrings makes it so that every user of each fstring benefit
from the memoized hash.

## Evaluation

The included benchmark hash_aref_fstr.rb is about 20% faster with this optimization.
hash_aref_long_str.rb shows that for long strings which we cannot memoize, there is
no visible performance penalty.

vm2_freezestring.yml is also not visibly slower after this optimization.

I have also attached a bechmark (string_key_vs_symbol_key.rb) that compares hash
lookups with symbols against hash lookups with strings. With this optimization, the
gap in performance is smaller. (10% slower post patch vs 30% slower on trunk)

---Files--------------------------------
string_key_vs_symbol_key.rb (594 Bytes)
0001-Hash-code-memoization-for-short-fstrings.patch (3.62 KB)
0001-Hash-code-memoization-for-short-fstrings-v2.patch (4.29 KB)
0001-Hash-code-memoization-for-short-fstrings-v3.patch (4.36 KB)
0001-Hash-code-memoization-for-short-fstrings-v4.patch (4.31 KB)
0001-Hash-code-memoization-for-short-fstrings-v5.patch (12.9 KB)
0001-Add-st_update_with_hash.patch (3.09 KB)
0002-Hash-code-memoization-for-short-fstrings.patch (10 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>