On Thu, Aug 05, 2021 at 04:53:38PM +0000, someone via Digitalmars-d-learn wrote: [...] > I already assumed that loading the data from file is a goner. > > So this leaves me with two choices: > > - keep the code as it is incurring higher-than expected > compilation-time: this is solely used in a module to build classes, I > guess pretty minimal usage, but I don't know where this app will > eventually go so better get it right to begin with > > - find a better alternative [...]
I'd say if the performance hit isn't noticeably bad right now, don't worry too much about it. You can always replace it later. One thing I really like about D is how easily refactorable D code tends to be. If you structure your code in a way that keeps separate concerns apart (and D features like metaprogramming really help with this), replacing your implementation choice with something else often turns out to be surprisingly simple. But if you expect to process very large data files at compile-time, I'd say consider generating the classes via a utility D program that emits D code as a separate step. In one of my projects I have a whole bunch of 3D model files that I need to convert into a format more suitable for use at runtime. I eventually opted to do this as a separate step from the main compilation: a helper utility to parse the files, massage the data, then spit out a .d file with the right definitions (including embedded array literals for binary data), then compile that into the main program. Since the data rarely changes, it's a waste of time to keep regenerating it every time I recompile; keeping it as a separate step means I only need to rerun the helper utility when the data actually changes as opposed to every single time I change 1 line of code. T -- Those who don't understand Unix are condemned to reinvent it, poorly.