Optimizing http.Dir Questions about backward compatibility?


If there are no errors, http.Dir calls os.Open once every time Open is called. If the file has not changed, performance can be improved by reducing system calls by caching *os.File and byte read from *os.File.


One implementation that comes to mind is to determine whether a file has been modified based on whether the file modification time has changed.
A prototype in a third-party library shows that this does improve performance.
However, in my thinking before sending CL, it occurred to me that my implementation relies on the assumption that the file modification time remains unchanged while the file content remains unchanged. I am not sure whether this conforms to the go1 compatibility promise. Not sure if you need to add the GODEBUG environment variable to preserve the old behavior?

I need help to solve the above problem that is preventing me from sending CL! If anyone can answer the above questions, thank you very much!

What do you mean by sending CL?

The implication of this is that I plan to send a CL to go’s http library for the optimization mentioned above.

Imho this implementation will not be added into the standard library. It’s very use case specific, and relies on a not very trustworthy parameter: modification date. It raises more questions, than give answers. To get mod time, go still needs to do a syscall Stat on a file to get it’s updated data. Imagine the name of the file changed, but insides didn’t. So, you will make 2 syscalls, stat and open instead of one. Someone can change file’s data without modifying its stats. And so on. And, don’t forget one of the main go mantras, http.Dir is a standard implementation of the FileSystem interface. Which means you can always implement and add a more personalised solution for you particular question, such as adding cache of files.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.