I’m not knowledgeable developer; the whole lot I do related to constructing software program is as a result of I get pleasure from it. Due to this, I don’t spend a variety of time optimizing and I’ve a variety of areas of ignorance round this. I used to be just lately studying up on embed and had a thought; does embed supply a efficiency benefit over os.ReadFile() or ioutil in getting bytes right into a byte slice? I might see this being the case, with the file knowledge being loaded into reminiscence at runtime and so being instantly out there when wanted, versus studying from disk, however I might additionally think about a state of affairs the place Go has been architected in a was that caches the info on disk to assist forestall blowing out the RAM funds.
Hello! embed doesn’t use os package deal and it does a uncooked studying of a file or dir utilizing the fs module as a substitute, saving actually the file content material right into a string, executing a direct mapping of the file content material on disk. At runtime you don’t have the latency of opening it utilizing os features, which additionally does a variety of methods behind the scene (in some conditions you need keep away from them). So, if you’d like use a read-only db file or textual content file, configuration and so forth, embed characteristic is admittedly helpful.
BUT, embedding a full file o dir content material right into a Go binary doesn’t imply it’s all in reminiscence at runtime, as a result of binaries are loaded by OS a bunch at a time on demand, and being a part of the binary the identical can occur for the embedded file if it’s a bit giant. This truth doesn’t rely on Go runtime or compiler.
1 Like
Thanks for the nice response.
1 Like
