4 ms·
@davidyeager: In the legend of the graph in Dynimizer System Overhead in https://dynimize.com/product https://dynimize.com/product, both series are labelled as
by ggambetta 8y ago
@davidyeager: In the legend of the graph in Dynimizer System Overhead in https://dynimize.com/product https://dynimize.com/product, both series are labelled as "Without Dynimizer".
Couple of questions. Since this seems to be a very general technology, why the emphasis on MySQL (and DBs in general)? Marketing? Also, I found Dynimize vs Dynimizer confusing - is that company name vs product name?
- davidyeager 8y agoYes we will correct the legend in that graph, thanks for reporting it. Dynimize is the company, Dynimizer the product. We may ditch the name Dynimizer and just go with Dynimize to avoid confusion. Thoughts? It is a general purpose approach to optimization and MySQL is just a starting point. It was chosen first because it has a broad user base and is relatively easier to support compared to many other Linux programs: single process architecture, long process lifetimes, OLTP workloads are known to spend much of their time in front-end CPU stalls on the CPU side which are effectively targeted with profile guided compiler optimizations, and it’s statically compiled. We’ve tried it on MongoDB and seen similar benefit but not supported yet. Coming soon. Windows will probably require some driver development for effective sample based profiling and will happen later on. We will improve the effectiveness of our other optimizations that don’t target front-end CPU stalls and better support multiprocess workloads with short process lifetimes, which will allow us to target many other types of programs in the future. Hope that clarifies things a bit.