noun: don't add identical values to song_x_cape's hashtable

We were unconditionally adding equal items to the hashtable of
already-compared pointers.  This table exists so that if we've already
determined two non-pointer-equal nouns are value-equal, we don't have to
check them again.  However, atoms (especially direct) ended up in this
hashtable even though we don't look those up.  This makes sure we don't
add items to the hashtable if they're "pointer"-equal (which for direct
atoms is value-equal).

The impact of this inefficiency was greatly magnified by the issue with
+mug where (mug a a) = (mug b b) for all a, b.  For this reason, these
identical pairs added to the hashtable always had the same mug, so they
were added to the same bucket, which meant adding to that list required
linearly traversing the entire bucket.

This was the first barrier that was causing |pack to take a long time on
ships which distribute OTAs, but it isn't a complete solution for |pack.
This commit is contained in:
Philip Monk 2020-07-15 12:33:54 -07:00
parent 462a3429ef
commit 7ded3f127c
No known key found for this signature in database
GPG Key ID: B66E1F02604E44EC

View File

@ -373,11 +373,13 @@ _song_x_cape(c3_ys mov, c3_ys off,
// we cons [a] and [b] as posts so that we don't
// touch their reference counts.
//
key = u3nc(u3a_to_off(a), u3a_to_off(b));
u3t_off(euq_o);
u3h_put(har_p, key, c3y);
u3t_on(euq_o);
u3z(key);
if ( a != b ) {
key = u3nc(u3a_to_off(a), u3a_to_off(b));
u3t_off(euq_o);
u3h_put(har_p, key, c3y);
u3t_on(euq_o);
u3z(key);
}
fam = _eq_pop(mov, off);
}