Zaur Shibzukhov, 05.03.2013 07:21:
In ExprNodes.py there are several places where method `as_none_safe_node`
was applied in order to wrap a node by NoneCheckNode.
I think it would be resonable to apply that mostly only in cases when
noncheck=True.
Here are possible changes in ExprNodes.py:
https://github.com/intellimath/cython/commit/bd041680b78067007ad6b9894a2f2c18514e397c
I consider the nonecheck option a quirk. In many, many cases, it's not
obvious to a user to what constructs it applies. For example, we use it to
guard against crashes when we optimise code, e.g. by inlining parts of a
C-API function, when iterating over builtins, etc. In most of these cases,
it depends on more than one parameter if the optimised code will be applied
(and thus no None check) or the fallback, which usually does its own
complete set of safety checks. So it's one of those options that may work
safely in all unit tests and then crash in production.
Remember, most cases where we leave a None check in the code are not those
where it's obvious that a variable cannot be None because it was just
assigned a non-None value. Most cases are about function arguments, i.e.
values that come from outside of the current function, and thus are not
obviously correct even for the human reader or author of the code.
Also, I'm yet to see a case where a None check really makes a difference in
performance. Often enough, the C compiler will be able to move them out of
loops or drop them completely because it already saw a None check against
the same local variable earlier on. In those cases, it's just Cython not
being smart enough to drop them itself, but without an impact on runtime
performance. And even if the C compiler is not smart enough either, at
least the branch prediction of the processor will strike in the relevant
cases (i.e. inside of loops) and reduce the overhead to pretty much zero.
All of this makes em think that we should be very careful when we consider
this option for the generated code.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
