New database manager #756
New database manager #756
Conversation
perf msg
use bytesIO fix SET += is slightly better than extend
foo reorg foo bug fixed cosmetic fix closing fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to give rename suggestions and tear them apart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's some preliminary review. If you don't mind, I might take this and re-work it a little to see whether I can find a nice middle ground. The schema.py
approach seems like it may add more complexity than is strictly necessary and make the actual server and client implementations a little harder to understand. (probably not something I'll do right away).
@pipermerriam Thank you for the review. Addressed the comments.
Feel free to do so. |
Closing as this has landed with #859 |
What was wrong?
Currently, Trinity client creates an extra process for each database consumer, this cause overheads and performance degrade.
How was it fixed?
Write a DB manager that handles all the communication to the database and a DB client that talks to the manager.
Benchmark shows the new DB manager-client has 1.5x to 2x performance comparing to the existing one.
To-Do
Cute Animal Picture