Re: [Zope3-dev] Re: AdapterLookup C optimizations 'timeit' benchmarks

2005-08-14 Thread Jim Fulton

Philipp von Weitershausen wrote:

Martijn Faassen wrote:


...


I think we should see to it that in cases of parallel implementations,
unit tests are set up to run twice, once for the Python implementation
and once for the C one. That way, by the rule of checking in no code
that produces unit test failures,  you are forced to modify both
implementations when you modify, fix a bug, etc. in either one.


Agreed, although I'm not sure how to do that. I'm sure we can figure
out something.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: AdapterLookup C optimizations 'timeit' benchmarks

2005-08-06 Thread Martijn Faassen

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:


On Friday 05 August 2005 09:46, Benji York wrote:


By my estimations(i hope i'm not wrong :) C version gives ~20-26% speed
up for different methods.


Running the functional tests for a Zope 3 based systems with 434 tests
yielded (best of 3) a time of 1:12.51 for the trunk and 1:12.32 for the
branch.  That's about a 0.25 percent improvement.


That's a bad argument. Several projects only use zope.interface and its 
adapter registry (for example twisted). For them a 20-26% improvement for the 
adapter lookup would be significant. Just because other parts of Zope 3 are 
even slower and use more time than the adapter lookup, it does not have to 
mean that this is a bad/insufficient improvement.


The tradeoff is complexity / loss of maintainability vs. speedup.  If
Benji's measurements hold up, we would be taking on the burden of
maintaining a parallel C implementation (in sync with the "canonical" C
version) within our project, for the (possible) benefit to other projects.


I also hope that in this case (unlike some other cases in the Zope 3 
source code), a parallel Python version *will* be maintained and 
continue to be tested. I ran into some problem with non-functioning 
stuff (debugging logs) in the security implementation, most likely 
because of a C implementation getting hooked in after the original code 
was written (compounded by there being no tests to verify whether the 
security logging facility worked).


The big question is of course what the impact on the performance of a 
typical Zope 3 application will be. If it's minimal it's not really 
worth it.


Note that projects like PyPy are getting there slowly but steadily -- 
it's possible that in a year's time we may only need to do minimal 
tweaking of Python code to benefit from compilation-level benefits. In 
the mean time, Pyrex is another avenue that might be worthwhile exploring.


Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com