[pypy-dev] Avoiding code duplication

Armin Rigo arigo at tunes.org
Fri Apr 14 17:22:27 CEST 2006


Hi Antonio,

On Fri, Apr 14, 2006 at 04:53:28PM +0200, Antonio Cuni wrote:
> # lltypesystem
> def ll_listindex(lst, obj, eqfn):
>     items = lst.ll_items()
> (...)
>             if items[j] == obj:
> 
> # ootypesystem
> def ll_listindex(lst, obj, eqfn):
> (...)
>             if lst.getitem_nonneg(j) == obj:

> Another solution could be to add an extra level of indirection but I 
> guess this could bring to some efficiency penalty.

I think this is kind-of-reasonable.  The ADT method approach of the
lltypesystem was introduced late during the development of the rtyper;
by now, it would be reasonable to define common method names between the
ADT methods of the lltypesystem and the GENERIC_METHODS of the
ootypesystem.

I am unsure about the performance penalty.  The current version of many
ll helpers, for example, read the 'items' pointer only once and reuse
it; if this gets replaced by ADT methods like 'getitem_nonneg()', it
means that althought the call is probably inlined there is still the
overhead of reading 'items' through each iteration in the list.  Who
knows, maybe C compilers will notice and move the read out of the loop.
Just give it a try on a small example like ll_listindex(), I guess...

A different comment: as you mentioned on IRC it would be nice if the
back-end could choose which methods it implements natively.  At one
point there was the idea that maybe the 'oopspec' attributes that
started to show up in lltypesystem/rlist.py (used by the JIT only) could
be useful in this respect.  If I remember correctly, the idea didn't
work out because of the different 'lowleveltype' needed, and the
difference in the interface.  Merging the ADT method names of lltyped
lists and the GENERIC_METHODS of ootyped lists could be a step in this
direction again.  The interesting point is that each oo back-end could
then choose to special-case the ll_xxx() functions with the oopspecs
that they recognize, and just translate the other ones normally.  (The
ll back-ends always translate them all.)


A bientot,

Armin.



More information about the Pypy-dev mailing list