I've actually considered doing something like this but didn't do so for two reasons:
The Loading stage loads the data from the LDraw files into memory in structures that contain all the data from the files, but that's about it. (It also constructs a tree representing all the files referenced in the model, reusing files that are reused.) Very specifically the data structures at this point are not graphics-specific (and in fact get used directly for my POV exporting). I could create a binary cache of the data at this point, but that's only about 20% of the total load time, so it's not particularly useful.
The Calculating Size stage does basically what it says it does, and wouldn't be aided by caching of the parts.
The Parsing stage transforms the data from the original format into the format I need for my graphics engine, and also performs primitive substitution and curve smoothing. I could create a binary cache of the final processed data, but LDView relies on the original data from the Loading stage for various functions, so I'd need to either create a separate cache for that, or simply still load the original LDraw files for that step, or go through a major rearchitecture of LDView so it didn't rely on that data. All of those options are fairly major, so caching has been put on the back burner.
To make things even more complicated, the results of both the Loading stage and the Parsing stage are different based on what options are selected in LDView. As one example, if you ask for low-res studs, it loads the low-res stud files from disk instead of the normal ones. It doesn't load both, so the data I get is different depending on that setting. Similarly, if you turn on Primitive Substitution, you get different geometry out of the Parsing stage than you get if that feature is disabled. So any caching in LDView would have to take this into account, thus complicating things quite a bit more than they already were.
- It's a fairly involved feature, and requires careful thought. Cached data needs to contain a timestamp, and any parts that are updated in the library need to automatically trigger regeneration of the cached data.
- LDView's architecture makes it less useful than it otherwise might be (see below).
The Loading stage loads the data from the LDraw files into memory in structures that contain all the data from the files, but that's about it. (It also constructs a tree representing all the files referenced in the model, reusing files that are reused.) Very specifically the data structures at this point are not graphics-specific (and in fact get used directly for my POV exporting). I could create a binary cache of the data at this point, but that's only about 20% of the total load time, so it's not particularly useful.
The Calculating Size stage does basically what it says it does, and wouldn't be aided by caching of the parts.
The Parsing stage transforms the data from the original format into the format I need for my graphics engine, and also performs primitive substitution and curve smoothing. I could create a binary cache of the final processed data, but LDView relies on the original data from the Loading stage for various functions, so I'd need to either create a separate cache for that, or simply still load the original LDraw files for that step, or go through a major rearchitecture of LDView so it didn't rely on that data. All of those options are fairly major, so caching has been put on the back burner.
To make things even more complicated, the results of both the Loading stage and the Parsing stage are different based on what options are selected in LDView. As one example, if you ask for low-res studs, it loads the low-res stud files from disk instead of the normal ones. It doesn't load both, so the data I get is different depending on that setting. Similarly, if you turn on Primitive Substitution, you get different geometry out of the Parsing stage than you get if that feature is disabled. So any caching in LDView would have to take this into account, thus complicating things quite a bit more than they already were.