I am not a professional developer; everything I do associated with building software is because I enjoy it. Because of this, I don’t spend a lot of time optimizing and I have a lot of areas of ignorance around this. I was recently reading up on embed and had a thought; does embed offer a performance advantage over os.ReadFile() or ioutil in getting bytes into a byte slice? I could see this being the case, with the file data being loaded into memory at runtime and so being immediately available when needed, as opposed to reading from disk, but I could also imagine a scenario where Go has been architected in a was that caches the data on disk to help prevent blowing out the RAM budget.
Hi! embed doesn’t use os package and it does a raw reading of a file or dir using the fs module instead, saving literally the file content into a string, executing a direct mapping of the file content on disk. At runtime you don’t have the latency of opening it using os functions, which also does a lot of tricks behind the scene (in some situations you want avoid them). So, if you want use a read-only db file or text file, configuration and so on, embed feature is really useful.
BUT, embedding a full file o dir content into a Go binary doesn’t mean it’s all in memory at runtime, because binaries are loaded by OS a bunch at a time on demand, and being part of the binary the same can happen for the embedded file if it is a bit large. This fact doesn’t depend on Go runtime or compiler.
1 Like
Thank you for the good response.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.