Re: Benchmarking SQL drivers
"Stephen R. van den Berg" <[email protected]>
| Newsgroups | gmane.comp.lang.pike.user |
|---|---|
| Message-ID | <[email protected]> |
Per Hedbor () @ Pike (-) importm?te f?r mailinglistan wrote: >>Getting even higher performance means that I would have to abandon the >>Pike-only driver solution, and I would have to start using a cmod >>helper module again. >Nice results. I am considering writing a pike mysql driver, thus >getting rid of yet another 'must install' package when building pike. Is the MySQL network protocol sufficiently stable? But, yes, pgsql shows that it is doable and it is quite likely that one can match or even improve on the C-lib version. In case of pgsql, there are two main reasons why it can beat the native C-drivers: - It is able to utilise network protocol features which the native C-driver doesn't (fully) exercise (binary/smart batching/multiple queryportals). - It is able to use the (idle) time between network packets to do some (pre/post)processing, thus lowering the overall latency. I'd guess that the MySQL network protocol offers similar opportunities. Incidentally, I checked to see what the performance difference is between storing undecoded row-blobs (in pgsql) vs. carving out the columns and creating the result array in Pike, it turns out to be some 15% max speedup (for the simple two-column test-query), but even if that decoding is to be done in C, it still is going to consume CPU, so in effect adding back a dedicated C-helper is not really effective (and would, yet again, introduce a potential source of bugs, and is not as easy to maintain). >By the way, with regards to c71051037ee, "Workaround c?-> bug": >It is not really a bug. The issue you are having is that the final >apply () operator is not conditional (so the fix is not complete, you >will still get errors if the connection is gone, as an example). Well, technically it may not be a bug, but currently it violates the "principle of least surprise". >After a ?-> in an expression (tree), set a flag to indicate that any >APPLY:s should return 0 if they are called on 0. >It would be fairly trivial, and make the ?-> operator do what people >expect it to, allowing you to type things like fd?->query_fd(). Sounds good. But I'll leave the expression tree fiddling to you :-). -- Stephen.