[Python-Dev] insertdict slower?

[Tim Peters]

[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