[Jeremy Hylton]
> I wanted to be sure that some other change to the dictionary code
> didn't have the unintended consequence of slowing down insertdict.
Have you looked at insertdict? Again, nothing has changed in it since 2.0,
and it's a simple little function anyway. Here it is in its entirety:
static void
insertdict(register dictobject *mp, PyObject *key, long hash, PyObject
*value)
{
PyObject *old_value;
register dictentry *ep;
ep = (mp->ma_lookup)(mp, key, hash);
if (ep->me_value != NULL) {
old_value = ep->me_value;
ep->me_value = value;
Py_DECREF(old_value); /* which **CAN** re-enter */
Py_DECREF(key);
}
else {
if (ep->me_key == NULL)
mp->ma_fill++;
else
Py_DECREF(ep->me_key);
ep->me_key = key;
ep->me_hash = hash;
ep->me_value = value;
mp->ma_used++;
}
}
There's not even a loop. Unless Py_DECREF got a lot slower, there's nothing
at all time-consuming in inserdict proper.
> There is a real and measurable slowdown in MAL's DictCreation
> microbenchmark, which needs to be explained somehow. insertdict
> sounds more plausible than many other explanations.
Given the code above, and that it hasn't changed at all, do you still think
it's plausible? At this point I can only repeat my last msg: perhaps your
profiler is mistakenly charging the time for this line:
ep = (mp->ma_lookup)(mp, key, hash);
to insertdict; perhaps the profiler is plain buggy; perhaps you didn't
measure what you think you did; perhaps it's an accidental I-cache conflict;
all *I* can be sure of is that it's not due to any change in insertdict
<wink>.
try-the-icache-trick-you-may-get-lucky-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4