Speed: bytecode vz C API calls

Jacek Generowicz jacek.generowicz at cern.ch
Tue Dec 9 22:31:15 CET 2003


"Terry Reedy" <tjreedy at udel.edu> writes:

> "Jacek Generowicz" <jacek.generowicz at cern.ch> wrote in message
> news:tyfy8tmz7hq.fsf at pcepsft001.cern.ch...
> > "Terry Reedy" <tjreedy at udel.edu> writes:
> > > Can any of your callables be memoized by list rather than dict?
> > > (ie, any count or restricted int args?)
> >
> > You've lost me there.
> 
> Lookup tables.  Dicts can memoize any function.  Lists can memoize or
> partially memoize functions with one or more periodic domains.  Perhaps I am
> being too obvious or simple for *you*, but I have seen people memoize fib()
> or fac() with a generic dict-based wrapper, which is overkill compared to a
> simple list.

The arguments passed to the functions I have memoized are usually
types, so, no, I cannot memoize them by list.

> In another post, you said
> 
> > If I want to compete on speed with C++, I'm
> >simply going have to eliminate Python bytecode from my inner loops[*].
> > [*] Unless my overall algorithm is completely wrong, of course.
> 
> For speed, you need to eliminate *executed* and *expensive* bytecodes, not
> static, possibly skipped-over, bytecodes.  I'll take that as what you meant.
> It is certainly what our comments are aimed at.  Hence my other suggestion
> to eliminate a layer of (expensive) function calls by combining value
> calculation and storage in one function (more space, less time).

You are suggesting that I hand-memoize my functions, rather than using
the generic memoizer I posted at the top of the thread? in order to
save, in the case of cache misses, the function call overhead to the
memoized function? If I had a high proportion of cache misses, then I
suspect that would be worth while. In my case, however, I doubt that
would have any appreciable effect. Almost all the calls to the
memoized functions are cache hits, so effectively there is no value
calculation ... it's pretty much all lookup, so my "expensive"
function is *effectively*:


  def proxy(*args):
      try:
          return cache[args]
      except KeyError: pass

(where proxy is a closure over cache). Yes, there is something other
than "pass" in the handler, but we (essentially) never go there.

There's really not much left to play with (though I'm open to
suggestions), which is why I wanted to try recoding in C.




More information about the Python-list mailing list