15 ms·
Huh? Your having a big monolith service binary doesn't mean that this whole binary gets paged in from disk all the time for every request. If you're specializin
by quotemstr 8y ago
Huh? Your having a big monolith service binary doesn't mean that this whole binary gets paged in from disk all the time for every request. If you're specializing and dedicating particular instances to particular tasks, you'll get cache-mediated locality even if you have a big binary that can, in principle, do lots of different things.
- jedberg 8y ago> doesn't mean that this whole binary gets paged in from disk all the time for every request No, but unless I'm reading this wrong, what this optimizes is what does get paged in. Using microservices would naturally limit what could get paged in because the services would most likely be smaller, whereas with this, the developer doesn't have to worry about those things and instead this tool optimizes for them.
- ebikelaw 8y agoIn my experience if you take one big service and break it into two, each binary will be pretty much just as big as the original. All of that library code is still in there, all that static data is still reachable. Nobody knows why but it is.
- repsilat 8y agoSure, but it's probably not all being executed, so you don't really pay for what you don't use. (OTOH, while you may not find yourself waiting on instructions, you'll no doubt spend all of your time waiting on data...)
- pjc50 8y agoIt's not really much to do with what gets paged in, more to do with instruction cache locality and all sorts of tiny micro-optimisations, especially relating to branches. If re-ordering code or adding branch-expected markers causes the branch predictor to guess correctly more often, it can have a huge benefit.