On Mon, 24 Jan 2005 03:11:05 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Replacing METH_O and METH_NOARGS seems straight-forward, but
> METH_VARARGS has much broader capabilities. How would you handle the
> simple case of "O|OO"? How could you determine useful default values
> (NULL, 0, -1, -909, etc.)?
I have a new version of the patch that handles this condition.
I pass NULLs for non-existant optional parameters. In your
case above, the arguments passed would be:
(obj, NULL, NULL)
This is handled pretty cleanly in the callees, since it is
pretty common to initialize optional params to NULL.
> If you solve the default value problem, then please also try to come up
> with a better flag name than METH_ARGS which I find to be indistinct
> from METH_VARARGS and also not very descriptive of its functionality.
> Perhaps something like METH_UNPACKED would be an improvement.
I agree METH_ARGS is a poor name. UNPACKED is fine with me.
If I don't hear a better suggestion, I'll go with that.
> > The drawbacks are:
> > * the defn of the MethodDef (# args) is separate from the function
> defn
> > * potentially more error prone to write C methods???
>
> No worse than with METH_O or METH_NOARGS.
I agree, plus the signature changes if METH_KEYWORDS is used.
I was interested if others viewed the change as better, worse,
or about the same. I agree with /F that it could be a disaster
if it really is more error prone. I don't view the change as
much different. Do others view this as a real problem?
> If speed is the main advantage being sought, it would be worthwhile to
> conduct more extensive timing tests with a variety of code and not using
> a debug build. Running test.test_decimal would be a useful overall
> benchmark.
I was hoping others might try it out and see. I don't have access
to Windows, Mac, or other arches. I only have x86 and amd64.
It would also be interesting to test this on some real world code.
I have tried various builtin functions and methods and the gain
seems to be consistent across all of them. I tried things like
dict.get, pow, isinstance. Since the overhead is fairly constant,
I would expect functions with more arguments to have an even
better improvement.
> In theory, I don't see how you could improve on METH_O and METH_NOARGS.
> The only saving is the time for the flag test (a predictable branch).
> Offsetting that savings is the additional time for checking min/max args
> and for constructing a C call with the appropriate number of args. I
> suspect there is no savings here and that the timings will get worse.
I think tested a method I changed from METH_O to METH_ARGS and could
not measure a difference. A beneift would be to consolidate METH_O,
METH_NOARGS, and METH_VARARGS into a single case. This should
make code simpler all around (IMO).
> In all likelihood, the only real opportunity for savings is replacing
> METH_VARARGS in cases that have already been sped-up using
> PyTuple_Unpack(). Those can be further improved by eliminating the time
> to build and unpack the temporary argument tuple.
Which this patch accomplishes.
> Even then, I don't see how to overcome the need to set useful default
> values for optional object arguments.
Take a look at the updated patch (#2). I still think it's pretty clean and an
overall win. But I'd really like to know what others think. I also implemented
most (all?) of METH_O and METH_NOARGS plus many METH_VARARGS, so
benchmarkers can compare a difference with and without the patch.
Neal
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
