On Mon, May 16, 2016 at 9:37 AM, Maciej Fijalkowski <fij...@gmail.com> wrote: > I don't think pypy is expected to speed up program where the majority > of the time is spent in copy.deepcopy. The answer to this question is > a bit boring one: don't write algorithms that copy around so much > data.
I hadn't expected the copy time to dominate, but I suspect that's because the state object was more complex than I was giving it credit for (large sets of tuples all nicely hidden away under an abstraction layer, that kind of thing). I was still surprised about the other 50% of the runtime not decreasing much (the actual state transformation part), but I'm not particularly concerned with that right now, as I'm in the process of restructuring the code to be copy on write (which is turning out to be less work than I was originally concerned it would be). > I'm sorry we can't give you a very good answer - if you really *NEED* > to do that much copying (maybe you can make the copy more lazy?), then > maybe shrinking the data structures would help? I can't answer that > without having access to the code though, which I would be happy to > look at. Thank you for the offer. If I still am not seeing results after the refactor, I might take you up on that. Since I don't have IP rights to the game in question, would it be acceptable to add you to a private repo on github (should we get to that point)? Thanks, Eli _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
