Comments (7)
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 callobject.__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.
Related Issues (20)
- __dataclass_fields__ is missing HOT 3
- TypeError: argument of type 'NoneType' is not iterable HOT 3
- Add Python 3.10 to CI HOT 2
- Tests: make signature checks version-agnostic HOT 1
- __post_init__ and repeated decorator produces max recursion depth HOT 2
- Removing support for post-initialisation logic in `__init__`
- Question - How does this play with dacite? HOT 2
- Inheriting from a dataclass using ABCMeta causes `AttributeError` HOT 21
- Python 3.10 pattern matching HOT 6
- Circular references to dataclasses cause infinite recursion in __repr__ HOT 3
- Multi-level inheritance causes __get__ to fail on properties HOT 3
- Derived classes with @dataclass(slots=True) generate empty __slots__ HOT 2
- Bug when mixing metaclasses w/ `dataclassy` (Python 3.6 only) HOT 8
- Internals are not considered in __eq__ HOT 10
- No "post-init only" marker HOT 1
- New mypy error with 0.11.0: Cannot instantiate type "Type[<nothing>]" HOT 2
- Error with dataclass with InitVar variable HOT 1
- Short-cut for the factory function (Feature request) HOT 2
- Late-init fields still appear in `__init__` HOT 1
- Add `internals` parameter to `as_dict`/`as_tuple` HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dataclassy.