-
Notifications
You must be signed in to change notification settings - Fork 118
#22 read_frame performance #24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Online github editor is unusable for editing python code...
|
👯 well done @tumb1er |
|
Sorry @tumb1er, but I couldn't see a performance improvement. Did you measure it? I made a simple test using IPython: %timeit MyModel.objects.all()[:1000].to_dataframe()Where Without your pull request I got about 32 ms. Besides, I have complex views using django-pandas and I didn't see a difference neither. :\ |
|
In fact, this pull request has a negative impact on performance if you use johnny-cache or django-cacheops. These two ORM caching tools are automatically saving in cache the data fetched by the ORM. With this pull request, the ORM builds the SQL query but it is executed by pandas. And therefore it disables these caching tools. |
|
Wel, django-cacheops is an excellent reason to close this issue :) |
|
I know pandas is made for Big Data, but I don't think anyone would allow django to retrieve > 100K rows as a view is meant to respond in less than 500 ms. By the way, what you did with the ValueQuerySets is good! In my opinion, we can merge the changes in manager.py and test_manager.py as is. |
|
It's not only about views, it's also about background report computations. So, 1M rows is OK :). By the way, you can add flag |
|
Yes, that |
|
so @tumb1er @BertrandBordage is there scope for a refactored PR to include the ValueQuerySet and the raw cursor stuff? |
|
I think that's a good idea! |
No description provided.