Re:Too much locality for stores to forward
by triztian on Sunday February 02, 2020 @02:36PM
(#22218864)
Seems like a good option would be to implement a second version that has the batch API but leave the line oriented one as is for use by the callers expect it to behave in a per-line oriented way.
Re:Too much locality for stores to forward
by magicalhippo on Sunday February 02, 2020 @02:40PM
(#22218895)
Yeah, still won't be easy to integrate the batch optimizations now, since all the code in this module is written with the single-line-at-a-time assumption.
Re:Too much locality for stores to forward
by spockz on Sunday February 02, 2020 @03:34PM
(#22219246)
It seems to me that this would be an area where something like reactive streams excel at. The interface is by default streaming and the code dealing with the database could decide to buffer the incoming stream to an optimal amount for creating a query. (Of course only buffering until a maximum latency was reached.) This way neither the producer nor the consumer need to be aware of the exact buffer requirements and the whole can be optimised using back pressure.
Re:Too much locality for stores to forward
by magicalhippo on Sunday February 02, 2020 @04:56PM
(#22219726)
Would be interesting to try, sadly not any library support in the language we use.
Re:Too much locality for stores to forward
by Retric on Sunday February 02, 2020 @04:07PM
(#22219423)
That opens things up for a host of long term maintenance issues. It might still be worthwhile, but itβs worth a serious discussion at a minimum.
Re:Too much locality for stores to forward
by vhvjkyhkogvv on Sunday February 02, 2020 @04:12PM
(#22219459)
If the single line one delegates to the batch one it should solve most of them.
Re:Too much locality for stores to forward
by hinkley on Monday February 03, 2020 @10:53AM
(#22225232)
starting with the innermost functions, especially those with no external caller, pluralize the function name and change the argument to be a list/array. Leave a thunking function at the old name that wraps the request and unwraps the response.
Lather rinse repeat until the entire module has been fixed, and start pushing it into the slowest callers.
Some intricate core code had to do like 10-15 queries per invoice line. Each is quick, but it adds up when you have 10k lines. The code my coworker wrote to do this was written in a per-line way.
Now, since this code was called from other parts of our program, where it might just operate on a single line, I couldn't just cache willy-nilly inside the module. If so I'd have to introduce some calls to invalidate the caches or whatnot. Easy to miss and easy to screw up and get stale data.
However, if instead the API had been batch oriented from the start, it would still work fine on a single line, but also allow for more optimizations for actual batches. The cases where it was called for a single line at a time was when the user was punching through, so being sub-optimal for that would not be an issue.
Gonna be fun trying to disentangle this and try to make it batch friendly...