Re: [nimh-dev] formats and execution speed

[Joel Uckelman <uckelman@xxxxxxxxx>]

Thus spake "Jon Stewart":
> 
> Well, it seems to me that a 50% reduction in running time is not out of 
> the question. Our implementation is by and large naive, and we're talking 
> performance of string formatting here, which is notoriously variable. 
> Also, you are scanning a relatively small folder. It would be good and 
> virtuous to run a set of comparisons a number of times on different sized 
> folders so we could do a linear regression. The startup cost from the 
> Python interpreter is going to be a large-but-constant hit on performance. 
> One obvious (but not especially trivial) way to address that is to fork a 
> python instance as a slumbering daemon the first time any command is run; 
> then it just does nothing as a background user process until the next 
> command is issued -- at which time it's immediately available. But that's 
> assuming python is like the JVM; I don't really know, but I suspect that 
> the eventual solution would be of a similar nature.
> 
> Also, my favorite open-source C++ library, Boost, has a component that you 
> can use to write python modules in C++. If we absolutely can't get format 
> performance to where we want it, it would be relatively easy to write the 
> default implementation in C++ and then call it from python.
> 
> I don't think we'll come close to matching nmh's performance, but I am 
> nonetheless optimistic about nimh's potential performance. I think it's 
> too early to worry.

Performance won't be an issue for anything except scan no matter how bad our
code is, since nothing else loops over formats. And it also only matters for
small folders. You won't notice the difference on folders with 10k messages
since you expect those to take a while to scan and you probaly aren't reading
the output anyhow.

_______________________________________________
nimh-dev mailing list
nimh-dev@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/nimh-dev