Windows Dev Center

Runtime Broker: High CPU usage after selecting lots of files


  • After acquiring a list of StorageFiles from the FileOpenPicker, I proceed to store their access token in the futureAccessList.

    Simple (CoffeeScript) code, so you can see there's not much going on: 

    storageFiles.forEach (file) ->

        token = StorageApplicationPermissions.futureAccessList.add file

    But when selecting a lot of files - let's say about 500 -, the Runtime Broker takes a lot of CPU for about 30-40 seconds, leaving the application totally unresponsive. I'm not sure how adding the token for a previously picked file to the futureAccessList can be such an expensive operation so I'm guessing there's something I'm doing wrong. I am aware that there's a limit on the futureAccessList, so this question is more targeted towards getting a better understanding of the platform than solving the actual issue at hand.

    Friday, March 30, 2012 8:45 AM


All replies

  • From the outside it seems like the list is a linear list so it would suffer as you add a lot of items.  Do you have an actual business case/scenario that you need so many files in this list?

    Jeff Sanders (MSFT)

    Friday, March 30, 2012 12:29 PM
  • Yes, indeed. Our application manages documents which are added by the user using the FilePicker. Now all access tokens are added to the futureAccessList, then each document is processed in a queue, removing the token once it has been processed.

    Directly operating on the list of StorageFiles returned from the picker isn't much of an option as processing may take some time - so we want to persist the queue, allowing the user to suspend and resume the application, continuing the import process where they left off.

    Monday, April 02, 2012 6:32 PM
  • Hi,

    I'm doing file queries at a frequency of ~ 1 query/second(a total of 10 queries) and I'm encountering the same problem. The Runtime Broker uses +90% of a quad core with hyperthreading activated, the memory usage jumps ~200MB and stays in this state for 1 min.

    Monday, May 07, 2012 1:17 PM
  • Does the memory then recover?

    Jeff Sanders (MSFT)

    Monday, May 07, 2012 1:56 PM
  • Yes, the memory recovers.
    Monday, May 07, 2012 2:14 PM
  • Good!  That is by design.  JavaScript recovers memory on idle (for performance reasons) and when you are in a tight loop like that you do not give the garbage collector time to reclaim the memory!  Marcus, I think this may be your issue as well... can you verify?


    Jeff Sanders (MSFT)

    Monday, May 07, 2012 2:22 PM