Performance.

[mtomasz-chromium]

I just checked version 1.3.0 and it's better but still slow. It seems that you're making a request for each onGetMetadataRequested, which is an overkill. I'd suggest you to cache metadata during listing directories (onReadDirectoryRequested) and use it for onGetMetadataRequested. That would boost the performance drastically. What do you think?

[yoichiro]

@mtomasz-chromium Agreed. Ok, I create the cache layer to store each metadata temporarily. For instance, I create the caching rule as like the following:

• The results of the onReadDirectoryRequested response are cached. If already exists in cache, it will be updated.
• When the onGetMetadataRequested fired, find the metadata from cache and return it if hit. Or, if nothing in cache, then fetch the metadata from the server and return it (should this response be cached?).

Well, I guess that the cached metadata should be expired after certain times. Tomasz, how many times do you think? If you have other idea, feel free to let me know that. :)

[mtomasz-chromium]

I think we can keep the cache until the directory is refreshed (new onReadDirectoryRequested arrives). As a result, the cache stays as long as user doesn't refresh the directory in Files app.

As for fallback in onGetMetadataRequested it depends. If we cached directory /hogefuga, and we request /hogefuga/1.txt then there is no need to do fallback. We can assume that cache is valid until the directory is refreshed (and new onReadDirectoryRequested is dispatched). If there is no /hogefuga/1.txt in the cache, but /hogefuga is cached, then we can safely return NOT_EXISTS.

But if we get a onGetMetadataRequested request for /hogefuga/1.txt and there is no /hogefuga cached, then we need a fallback. We can do it in two ways. Either fetch metadata, or just read /hogefuga directory and use it for the result of onGetMetadataRequested. What do you think about such strategy?

[yoichiro]

@mtomasz-chromium Probably, the 1st way "fetch metadata" looks good to me, because of reducing the communication... But I can almost understand this architecture, so I'll start to implement this. Give me a few days.

[yoichiro]

@mtomasz-chromium Also, I found the bottleneck. Currently, hidden files which has a name starts with "." are included. We can reduce the count of fetching metadata by removing them from the result of the onReadDirectoryRequested event.

[mtomasz-chromium]

Files starting with dot may be shown in Files app. You need to use the ctrl+dot shortcut (if I remember correctly).

[yoichiro]

@mtomasz-chromium Oh, I didn't know that. OK. I don't modify the code regarding fetching the file list including the file with dot.

[yoichiro]

@mtomasz-chromium I just created the diff to add the cache mechanism for each metadata object. https://github.com/yoichiro/chromeos-filesystem-sftp/pull/44/files

[yoichiro]

@mtomasz-chromium I just released the new version 1.4.0 including the modification to fix this issue.

[yoichiro]

@mtomasz-chromium I close this issue because the cache layer has been released.