Do you intend to rewrite the `copy` module?

0 views
Skip to first unread message

cool-RR

unread,
Dec 16, 2009, 7:12:52 PM12/16/09
to Unladen Swallow
Do you intend to rewrite or optimize the `copy` module from the
standard library?

Ram.

Collin Winter

unread,
Dec 16, 2009, 7:18:26 PM12/16/09
to cool-RR, Unladen Swallow
Hi,

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

cool-RR

unread,
Dec 16, 2009, 7:29:44 PM12/16/09
to unladen-swallow
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. Also I never created a benchmark for anything.

Ram.

Collin Winter

unread,
Dec 16, 2009, 7:34:13 PM12/16/09
to cool-RR, unladen-swallow
Hi Ram,

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

cool-RR

unread,
Dec 16, 2009, 7:36:04 PM12/16/09
to unladen-swallow


On Thu, Dec 17, 2009 at 2:34 AM, Collin Winter <collin...@google.com> wrote:
Hi Ram,

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


Right, that sounds reasonable.


Thanks for your time,
Ram.
Reply all
Reply to author
Forward
0 new messages