diff options
author | trav90 <travawine@palemoon.org> | 2018-08-18 15:18:52 -0500 |
---|---|---|
committer | trav90 <travawine@palemoon.org> | 2018-08-18 15:18:52 -0500 |
commit | 450eed08c5eb7de7928e185feaf79f0b74b932e5 (patch) | |
tree | 7fde5d4c4208c265e6254d8b6b09f7f4801188fd /tools | |
parent | f0a708834dfb189058dd90b67765fda7687f5039 (diff) | |
download | UXP-450eed08c5eb7de7928e185feaf79f0b74b932e5.tar UXP-450eed08c5eb7de7928e185feaf79f0b74b932e5.tar.gz UXP-450eed08c5eb7de7928e185feaf79f0b74b932e5.tar.lz UXP-450eed08c5eb7de7928e185feaf79f0b74b932e5.tar.xz UXP-450eed08c5eb7de7928e185feaf79f0b74b932e5.zip |
Avoid doing a memset on a non-POD structure
|entryCount| tracks -- in fast-to-check manner -- the number of entries in the hashtable. But to actually enumerate entries, we have to loop through all of |table|, checking for entries that are actually live. A live entry is indicated by a zero |hash| in the entry. The |memset| would properly zero that; removing the memset will not.
It's not entirely clear whether a memset that overwrites a lot of stuff but is maybe simpler, is faster than compiler-generated likely-SIMD code that zeroes out *just* |hash| fields in all the entries. But I am going to guess that SIMD is good enough. For now, we should just do the simple and thing: don't distinguish POD and non-POD, and know that the compiler is going to recognize that |mem.addr()->~T()| is a no-op when T is trivial. So with POD, the loop should degenerate to just zeroing |hash| at consistent offset, and SIMD will eat that up, and it can't be *that* different from the memset in performance (if it is at all).
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions