{"type":"rich","version":"1.0","author_name":"Tomas [ARCHIVE] (npub1rs…9evk4)","author_url":"https://nostr.ae/npub1rsp4w56r24w3zv4xy8zfgesep45qmf9rq6aghxfw3wr7yemqnnwsf9evk4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-07\n📝 Original message:Hi Eric,\n\nOn Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:\n\u003e Optimization for lower memory platforms then becomes a process of\n\u003e reducing the need for paging. This is the purpose of a cache. The seam\n\u003e between disk and memory can be filled quite nicely by a small amount\n\u003e of cache. On high RAM systems any cache is actually a de-optimization\n\u003e but on low RAM systems it can prevent excessive paging. This is\n\u003e directly analogous to a CPU cache. \n\n\nI am not entirely sure I agree with that, or understand it correctly.\n\nIf -for example - the data of some application is a set  of records\nwhich can be sorted from least frequently used to most frequently used\nthen doing just that sort will beat any application-layer cache.\nRegardless of size of data and size of RAM, you simply allow the OS to\nuse disk caching or memory map caching to work its  magic .\n\nIn fact, I would argue that an application-layer cache *only* makes\nsense if the data model shows a *hard* distinction between often and not\noften used data. If usage-frequency is a continuous line, caching is\nbest left to the OS by focussing on proper spatial and temporal locality\nof reference of your data, because the OS has much more information to\nmake the right decision."}