Ram.
On Wed, Dec 16, 2009 at 4:12 PM, cool-RR <ram.r...@gmail.com> wrote:
> Do you intend to rewrite or optimize the `copy` module from the
> standard library?
To my knowledge, the copy module has not shown up as
performance-critical in any of our benchmarks, or any of our internal
applications. Do you have an application where that module's
performance is important? Can that application be open-sourced, or a
representative benchmark distilled from it?
Thanks,
Collin Winter
On Wed, Dec 16, 2009 at 4:29 PM, cool-RR <coo...@cool-rr.com> wrote:
> Actually, my original gripe was not with its performance. The original thing
> that drove me to check out its source was trying to make a way to have
> several different copy modes, each behaving differently for different copy
> types. I will probably be able to do this regardless, but then I also
> noticed that the module is written messily. But maybe it's not of your
> concern in unladen-swallow.
> I do have an open-source application that's using `copy` heavily. It's
> called GarlicSim. It deals with world states in simulated worlds. Most
> simulation packages generate the next world state by deepcopying the current
> one. This is an operation that gets iterated for every new world state, i.e.
> thousands of times.
> I haven't profiled it and I don't know if `copy` is a bottleneck though.
Unladen Swallow is concerned primarily with performance, and there's
already a huge amount of work to be done in that area. Without hard
evidence that the copy module's performance is important to real-world
applications, we are unlikely to spend any time on it.
Thanks,
Collin Winter
Unladen Swallow is concerned primarily with performance, and there's
already a huge amount of work to be done in that area. Without hard
evidence that the copy module's performance is important to real-world
applications, we are unlikely to spend any time on it.
Thanks,
Collin Winter