Instantiation performance vs. dataclasses about dataclassy HOT 7 CLOSED

OK, the prototype is in performance. All tests pass (though it needs neatening) but I'm now off to enjoy the new year. Happy New Year to you too.

from dataclassy.

Hi there. I have been thinking about performance recently - for example see #10 where I am testing a change with the aim of improving performance in a different scenario. Earlier this month I created some rudimentary benchmarks and got the same results as you. Performance is something I am happy to focus on now I'm confident dataclassy has achieved its primary goal of being more expressive and enjoyable to use than dataclasses.

Now, as to what I think specifically:

• dataclasses is fast because it minimises the amount of time CPython has to spend executing Python on class initialisation. It does this by only touching __init__. dataclassy currently uses __new__ or __call__ to do initialisation so that it stays out of the user's way, allowing them to beautifully define an __init__ that takes the role of __post_init__. The initialisation logic between the two (setting instance variables to parameters) is identical; what slows this down is more or less having to call object.__new__ and return the object from Python.
• dataclassy absolutely can gain the same performance in the simple case. Changing it to generate __init__ instead of __new__ required a grand total of 4 lines of code to be changed and in my benchmarks results in identical (if not marginally better) performance to dataclasses. Of course this totally breaks the user-defined init feature, but this is an optimisation that can be made conditionally.
• This "pay for what you need" paradigm is appealing and wouldn't be difficult or especially longwinded to implement. I have a few ideas for other optimisations too, but they're much less dramatic than this.

from dataclassy.

OK, I realised that with the simplifications made to how initialisation works over the months I actually do not need to mess around with __new__ and __call__ and can do everything with __init__ meaning the performance upgrade is attainable across all use-cases. One test for decorator reuse on a blank class is failing which I still need to figure out the cause of.

from dataclassy.

Wow, that was quick! I tried the performance branch, and (for my use at least) it closely matches dataclasses' performance. Let me know if you want any help with further testing or implementation. Thanks, and happy new year to you too!

from dataclassy.

@TylerYep, would you be able to check the code in performance works in your applications? This is quite a big internal change and it would be good if a few people could check it doesn't break anything. It should also fix the instantiation performance problem you also noted in #6.

from dataclassy.

Hey, I tested it out (I checked ot the version of code on the open PR) and it works great!
Prior to this, dataclassy was taking around 30+ seconds to complete either of the two benchmark tests.

My quick benchmark (my application is essentially a SAT solver that creates roughly 2^n instances of the dataclass).
I am using cProfile to measure the runtimes.

                dataclasses         dataclassy
Small N:          2.2 sec            2.3 sec
Larger N:         4.7 sec            4.9 sec

from dataclassy.

Awesome, thanks!

from dataclassy.