3 ms·
Bold claims... Performance is evaluated against a single example implementation (section 6.1) and 9x improvement was achieved when co-locating into a single pr
by sgt101 3y ago
Bold claims...
Performance is evaluated against a single example implementation (section 6.1) and 9x improvement was achieved when co-locating into a single process. To be fair this seems a reasonable thing to do if you can get the application to be efficient enough to allow it - but there may be very good reasons not to do it in many applications.
- CharlieDigital 3y agoNetwork I/O is almost always the slowest part of any application regardless of the protocol and data encoding mechanism. It seems to reason that if you can co-locate your calls into a single process, you'd gain at least 9x.
- sgt101 3y agoYeah - I think that their argument would be that their approach enables you to do that, and that there are significant gains on the table without that last step. My main critique is that it's one example, and it would be good to see the technique exercised across a number so that we can see the strengths and weaknesses.
- bob1029 3y agoFor same process + core + hot cache & pipeline, your upper bound is something like 1,000,000x faster than a trip within the same datacenter. This intuition is what encouraged us to run with SQLite in production back when most developers didn't think it was a good idea.
- dti 3y ago~2.5x when not co-located isn't bad either; and the beauty of it is that the programming model lets the runtime system perform these relocations, based on the application profile.