What does Blink in-memory cache store?












10















Besides the browser cache, there are a few other ways browser cache data. For Chrome, there is another cache in the rendering engine Blink that stores images, styles, scripts and fonts (maybe more) in memory.



This cache is used for consecutive navigations on a site. Resources delivered from the Blink cache are tagged with (from memory cache) in the network tab. Resources served from the browser cache are tagged with (from disk cache).



My question is now, which resources are stored in and delivered from this very fast cache? From my tests, it varies a lot:




  • It works extremely well for images and script tag which are directly in the HTML.

  • It works sometimes for style (link) tags which are directly in the HTML. Sometimes it does not work (in the same browser with the same session).

  • It works almost never for script tags that are inserted into the HTML programmatically. Sometimes it works though.


One huge difference between disk cache hits and memory cache hits becomes visible in combination with Service Workers. Requests that are served by the in-memory cache cannot be observed in the Service Worker (because the cache comes before the Service Worker). Requests that are served by the disk cache pass through the Service Worker (since the Browser Cache lies behind Service Worker).



To show the explained behavior, I built a test page with all resource types: https://dm-clone-optimized.app.baqend.com/



You can navigate through the site with the links at the top and observe how the requests behave in the network tab and console. Every page loads the same resources.



After a bit of navigating (Chrome 70.0.3538.67), I get this behavior most of the time:
enter image description here




  • HTML is fetched from network

  • Script tags scripts.js and scripts2.js are from in-memory cache

  • Image tag logo.png is from in-memory as well

  • Style link tag styles.css is from disk cache :(

  • Programatically added script tag scripts2.js?id=1 is from disk cache as well :(


Sometimes though, I get really lucky and everything is served from in-memory cache:
enter image description here



I would love to understand how the Blink in-memory cache works and how I can tune my site to use it for all resources with appropriate cache control header.



---- edit ----



What concerns me the most is: Why are dynamically added scripts not cached at all? This has a noticeable impact on frameworks like scripts.js since they insert all dependencies as dynamically added script tags.










share|improve this question

























  • It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

    – user3474985
    Nov 26 '18 at 21:39











  • @user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

    – Erik
    Nov 27 '18 at 6:53






  • 1





    The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

    – Erik
    Nov 27 '18 at 6:53
















10















Besides the browser cache, there are a few other ways browser cache data. For Chrome, there is another cache in the rendering engine Blink that stores images, styles, scripts and fonts (maybe more) in memory.



This cache is used for consecutive navigations on a site. Resources delivered from the Blink cache are tagged with (from memory cache) in the network tab. Resources served from the browser cache are tagged with (from disk cache).



My question is now, which resources are stored in and delivered from this very fast cache? From my tests, it varies a lot:




  • It works extremely well for images and script tag which are directly in the HTML.

  • It works sometimes for style (link) tags which are directly in the HTML. Sometimes it does not work (in the same browser with the same session).

  • It works almost never for script tags that are inserted into the HTML programmatically. Sometimes it works though.


One huge difference between disk cache hits and memory cache hits becomes visible in combination with Service Workers. Requests that are served by the in-memory cache cannot be observed in the Service Worker (because the cache comes before the Service Worker). Requests that are served by the disk cache pass through the Service Worker (since the Browser Cache lies behind Service Worker).



To show the explained behavior, I built a test page with all resource types: https://dm-clone-optimized.app.baqend.com/



You can navigate through the site with the links at the top and observe how the requests behave in the network tab and console. Every page loads the same resources.



After a bit of navigating (Chrome 70.0.3538.67), I get this behavior most of the time:
enter image description here




  • HTML is fetched from network

  • Script tags scripts.js and scripts2.js are from in-memory cache

  • Image tag logo.png is from in-memory as well

  • Style link tag styles.css is from disk cache :(

  • Programatically added script tag scripts2.js?id=1 is from disk cache as well :(


Sometimes though, I get really lucky and everything is served from in-memory cache:
enter image description here



I would love to understand how the Blink in-memory cache works and how I can tune my site to use it for all resources with appropriate cache control header.



---- edit ----



What concerns me the most is: Why are dynamically added scripts not cached at all? This has a noticeable impact on frameworks like scripts.js since they insert all dependencies as dynamically added script tags.










share|improve this question

























  • It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

    – user3474985
    Nov 26 '18 at 21:39











  • @user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

    – Erik
    Nov 27 '18 at 6:53






  • 1





    The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

    – Erik
    Nov 27 '18 at 6:53














10












10








10


4






Besides the browser cache, there are a few other ways browser cache data. For Chrome, there is another cache in the rendering engine Blink that stores images, styles, scripts and fonts (maybe more) in memory.



This cache is used for consecutive navigations on a site. Resources delivered from the Blink cache are tagged with (from memory cache) in the network tab. Resources served from the browser cache are tagged with (from disk cache).



My question is now, which resources are stored in and delivered from this very fast cache? From my tests, it varies a lot:




  • It works extremely well for images and script tag which are directly in the HTML.

  • It works sometimes for style (link) tags which are directly in the HTML. Sometimes it does not work (in the same browser with the same session).

  • It works almost never for script tags that are inserted into the HTML programmatically. Sometimes it works though.


One huge difference between disk cache hits and memory cache hits becomes visible in combination with Service Workers. Requests that are served by the in-memory cache cannot be observed in the Service Worker (because the cache comes before the Service Worker). Requests that are served by the disk cache pass through the Service Worker (since the Browser Cache lies behind Service Worker).



To show the explained behavior, I built a test page with all resource types: https://dm-clone-optimized.app.baqend.com/



You can navigate through the site with the links at the top and observe how the requests behave in the network tab and console. Every page loads the same resources.



After a bit of navigating (Chrome 70.0.3538.67), I get this behavior most of the time:
enter image description here




  • HTML is fetched from network

  • Script tags scripts.js and scripts2.js are from in-memory cache

  • Image tag logo.png is from in-memory as well

  • Style link tag styles.css is from disk cache :(

  • Programatically added script tag scripts2.js?id=1 is from disk cache as well :(


Sometimes though, I get really lucky and everything is served from in-memory cache:
enter image description here



I would love to understand how the Blink in-memory cache works and how I can tune my site to use it for all resources with appropriate cache control header.



---- edit ----



What concerns me the most is: Why are dynamically added scripts not cached at all? This has a noticeable impact on frameworks like scripts.js since they insert all dependencies as dynamically added script tags.










share|improve this question
















Besides the browser cache, there are a few other ways browser cache data. For Chrome, there is another cache in the rendering engine Blink that stores images, styles, scripts and fonts (maybe more) in memory.



This cache is used for consecutive navigations on a site. Resources delivered from the Blink cache are tagged with (from memory cache) in the network tab. Resources served from the browser cache are tagged with (from disk cache).



My question is now, which resources are stored in and delivered from this very fast cache? From my tests, it varies a lot:




  • It works extremely well for images and script tag which are directly in the HTML.

  • It works sometimes for style (link) tags which are directly in the HTML. Sometimes it does not work (in the same browser with the same session).

  • It works almost never for script tags that are inserted into the HTML programmatically. Sometimes it works though.


One huge difference between disk cache hits and memory cache hits becomes visible in combination with Service Workers. Requests that are served by the in-memory cache cannot be observed in the Service Worker (because the cache comes before the Service Worker). Requests that are served by the disk cache pass through the Service Worker (since the Browser Cache lies behind Service Worker).



To show the explained behavior, I built a test page with all resource types: https://dm-clone-optimized.app.baqend.com/



You can navigate through the site with the links at the top and observe how the requests behave in the network tab and console. Every page loads the same resources.



After a bit of navigating (Chrome 70.0.3538.67), I get this behavior most of the time:
enter image description here




  • HTML is fetched from network

  • Script tags scripts.js and scripts2.js are from in-memory cache

  • Image tag logo.png is from in-memory as well

  • Style link tag styles.css is from disk cache :(

  • Programatically added script tag scripts2.js?id=1 is from disk cache as well :(


Sometimes though, I get really lucky and everything is served from in-memory cache:
enter image description here



I would love to understand how the Blink in-memory cache works and how I can tune my site to use it for all resources with appropriate cache control header.



---- edit ----



What concerns me the most is: Why are dynamically added scripts not cached at all? This has a noticeable impact on frameworks like scripts.js since they insert all dependencies as dynamically added script tags.







google-chrome caching rendering






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 29 '18 at 6:57







Erik

















asked Oct 23 '18 at 13:15









ErikErik

1,22821126




1,22821126













  • It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

    – user3474985
    Nov 26 '18 at 21:39











  • @user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

    – Erik
    Nov 27 '18 at 6:53






  • 1





    The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

    – Erik
    Nov 27 '18 at 6:53



















  • It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

    – user3474985
    Nov 26 '18 at 21:39











  • @user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

    – Erik
    Nov 27 '18 at 6:53






  • 1





    The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

    – Erik
    Nov 27 '18 at 6:53

















It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

– user3474985
Nov 26 '18 at 21:39





It's my understanding that cache-control doesn't really offer a level of granularity that could affect caching strategies implemented by the rendering engine. Unless you're looking for how Blink might interpret the max-age property? As a web content developer, you shouldn't really need to concern yourself with how Blink manages it's cache (in-memory vs disk) for the most part. I'm not sure how deep you dug into the Blink documentation but this presentation deck was interesting: docs.google.com/presentation/d/…

– user3474985
Nov 26 '18 at 21:39













@user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

– Erik
Nov 27 '18 at 6:53





@user3474985 It actually seems that the Blink cache obeys cache control directives like max-age. At least resources with max-age=0 no-cache no-store do not seem to be cached. What I'm wondering about is why dynamically added scripts are not cached at all (except some rare moments). Yoav Weiss and Jake Archibald also seem to think there is something odd about this, see Twitter conversation

– Erik
Nov 27 '18 at 6:53




1




1





The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

– Erik
Nov 27 '18 at 6:53





The reason I am concerned with this behavior is that it has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags. This is especially problematic if JavaScript is the performance bottleneck in a shop frontend for example.

– Erik
Nov 27 '18 at 6:53












2 Answers
2






active

oldest

votes


















1














Blink in-memory cache works



Blink has four memory allocators
PartitionAlloc, Oilpan, tcmalloc, and system allocator



So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink



Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8



Inside Blink, the primary memory consumers are:




  • Large StringImpls (used by JavaScript source code)

  • shared buffers (used by Resources)

  • Vectors and HashTables


The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."




  • Reducing the size of (DOM object) won’t have an impact

  • Discarding caches won’t affect in most cases


They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.






share|improve this answer































    1














    I believe it is a result of optimization in chrome, and they make it verbose to you.



    The files are always go into disk cache. And they also goes into memory, and flushed very soon.



    Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
    The step has a high hit rate, as those images/js are actively using for something.



    You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.



    P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.



    P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.






    share|improve this answer
























    • Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

      – Erik
      Nov 29 '18 at 6:55











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52950068%2fwhat-does-blink-in-memory-cache-store%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    Blink in-memory cache works



    Blink has four memory allocators
    PartitionAlloc, Oilpan, tcmalloc, and system allocator



    So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink



    Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8



    Inside Blink, the primary memory consumers are:




    • Large StringImpls (used by JavaScript source code)

    • shared buffers (used by Resources)

    • Vectors and HashTables


    The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."




    • Reducing the size of (DOM object) won’t have an impact

    • Discarding caches won’t affect in most cases


    They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.






    share|improve this answer




























      1














      Blink in-memory cache works



      Blink has four memory allocators
      PartitionAlloc, Oilpan, tcmalloc, and system allocator



      So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink



      Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8



      Inside Blink, the primary memory consumers are:




      • Large StringImpls (used by JavaScript source code)

      • shared buffers (used by Resources)

      • Vectors and HashTables


      The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."




      • Reducing the size of (DOM object) won’t have an impact

      • Discarding caches won’t affect in most cases


      They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.






      share|improve this answer


























        1












        1








        1







        Blink in-memory cache works



        Blink has four memory allocators
        PartitionAlloc, Oilpan, tcmalloc, and system allocator



        So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink



        Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8



        Inside Blink, the primary memory consumers are:




        • Large StringImpls (used by JavaScript source code)

        • shared buffers (used by Resources)

        • Vectors and HashTables


        The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."




        • Reducing the size of (DOM object) won’t have an impact

        • Discarding caches won’t affect in most cases


        They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.






        share|improve this answer













        Blink in-memory cache works



        Blink has four memory allocators
        PartitionAlloc, Oilpan, tcmalloc, and system allocator



        So the team working on Chrome Blink has removed tcmalloc and system allocators from Blink



        Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory which consumes 10 - 20% in typical cases and retains some of the memory in Discardable, CC and V8



        Inside Blink, the primary memory consumers are:




        • Large StringImpls (used by JavaScript source code)

        • shared buffers (used by Resources)

        • Vectors and HashTables


        The recommendation is to: "identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them."




        • Reducing the size of (DOM object) won’t have an impact

        • Discarding caches won’t affect in most cases


        They are working on getting rid of "DiscardableMemory" items which will help to do things like forcibly detaching all layout objects which in turn will release memory retained by the layout tree.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 28 '18 at 14:37









        UnPUnP

        8111




        8111

























            1














            I believe it is a result of optimization in chrome, and they make it verbose to you.



            The files are always go into disk cache. And they also goes into memory, and flushed very soon.



            Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
            The step has a high hit rate, as those images/js are actively using for something.



            You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.



            P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.



            P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.






            share|improve this answer
























            • Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

              – Erik
              Nov 29 '18 at 6:55
















            1














            I believe it is a result of optimization in chrome, and they make it verbose to you.



            The files are always go into disk cache. And they also goes into memory, and flushed very soon.



            Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
            The step has a high hit rate, as those images/js are actively using for something.



            You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.



            P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.



            P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.






            share|improve this answer
























            • Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

              – Erik
              Nov 29 '18 at 6:55














            1












            1








            1







            I believe it is a result of optimization in chrome, and they make it verbose to you.



            The files are always go into disk cache. And they also goes into memory, and flushed very soon.



            Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
            The step has a high hit rate, as those images/js are actively using for something.



            You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.



            P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.



            P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.






            share|improve this answer













            I believe it is a result of optimization in chrome, and they make it verbose to you.



            The files are always go into disk cache. And they also goes into memory, and flushed very soon.



            Chrome is smart enough to ask running process that do they still have a loaded copy of them in memory before seek on disk.
            The step has a high hit rate, as those images/js are actively using for something.



            You will not have any control how chrome manage TTL of them/capacity of memory could be used to keep blob hot. Chrome dev team doing quite a lots on dynamic tuning based on actual hardware capacity and system loading.



            P.S. If you are asking for keep YOUR APP in memory. You are failing into Sun/Adobe way of evil: making their app DLL hot in memory(by tray icon/service) and slow everyone else down.



            P.P.S. If it is the app end-user might want to use, use electron and follow Whatsapp/Slack/etc to build an app always running.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 28 '18 at 17:28









            Dennis CDennis C

            20k126394




            20k126394













            • Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

              – Erik
              Nov 29 '18 at 6:55



















            • Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

              – Erik
              Nov 29 '18 at 6:55

















            Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

            – Erik
            Nov 29 '18 at 6:55





            Hey @DennisC thanks for your answer. To eliminate the misunderstanding, my question is not about how Blink evicts entries to manage its memory but rather why dynamically added scripts are not cached at all (except some rare cases). This has a noticeable impact on frameworks like require.js since they insert all dependencies as dynamic script tags.

            – Erik
            Nov 29 '18 at 6:55


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52950068%2fwhat-does-blink-in-memory-cache-store%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            這個網誌中的熱門文章

            Xamarin.form Move up view when keyboard appear

            Post-Redirect-Get with Spring WebFlux and Thymeleaf

            Anylogic : not able to use stopDelay()