On Mon, May 16, 2016 at 6:53 PM, Eli Stevens (Gmail) <wickedg...@gmail.com> wrote: > 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
Sure, I don't mind. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
