"Martin v. Loewis" wrote:
>
> > > That's why I would like the simple
> > >
> > > if (v == w) return 0;
> > >
> > > integrated into the ceval loop right along the INT-compare
> > > optimization.
> >
> > Maybe this could be done as follows:
> >
> > if (v == w && PyString_CheckExact(v)) return 0;
>
> Maybe I'm missing some context here: where is this fragment supposed
> to go to? into ceval.c:COMPARE_OP? What is the "return 0;" doing then?
It's pseudo code I made up. The real thing will look very much
like it though.
> In any case, I think measurements should show how much speed
> improvement is gained by taking this short-cut. It sounds nice in
> theory, but ...
>
> I just added the block
>
> else if ((v == w) && (oparg == EQ) && PyString_CheckExact(v)) {
> x = Py_True;
> Py_INCREF(x);
> }
You should first test for oparg == EQ, then for v == w and
PyString_CheckExact().
> into the code. In an application that almost exclusively does
> COMPARE_OPs on identical strings, I got a 30% speed-up.
Nice :-)
> OTOH, this
> same code caused a 10% slowdown if I converted the "==" into "<>".
This sounds like an alignment problem caused by the compiler.
10% speedups/slowdowns can easily be produced by randomly moving
about a few cases in the ceval loop. All depends on the platform
and compiler though.
> In a real application, total speed-up will depend on two things:
> - how many COMPARE_OPs are done in the code?
> - how many of those compare identical strings for equality?
As I explained in my other reply, I have code which does:
if variable == 'constant string': ...
Since the compiler interns the 'constant string' and I can
make sure that variable is interned too (by calling intern()),
I can easily take advantage of the optimization without
giving away any semantics.
If variable happens to be some other constant which is
used in a Python module (e.g. some kind of flag or parameter),
then it will be interned per-se too.
Note that the dictionary implementation relies heavily
on the same optimization (interning was added to enhance
string compare performance in dict lookups).
> Running the PyXML test suite, I counted 120000 cases where
> slow_compare was done, and only 700 cases identical strings were
> compared for equality.
As Fred mentioned, this is probably due to the fact that
Unicode objects are not interned. Neither are typical
XML tag names; could make a difference... don't know.
I believe that PyXML spends most of the time in Python
calls and not so much in string compares (and that's what I'm
trying to avoid in my XML parser approach ;-).
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
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