No, it does not matter. I’ll now try to go into the technical details of how a CAD system works to explain why it doesn’t matter, but it’s a bit beyond the scope of this forum.
As a start, I recommend reading this article: The technological foundations of CAD software
In a parametric CAD system, under the hood what you need to store is a sequence of the operations, that looks something like this:
sketch (list of lines arcs constraints etc)
extrude (references to the sketch)
fillet (references to the extrusion)
etc.
This takes up very little storage. The output of these operations is a boundary representation (b-rep) data, which is the actual geometry.
The b-rep data stores all the faces and the edges (topology) and the surfaces and the curves (geometry).
A single spline surface can take up more space than the entire parametric history of a complex geometry, because every point, every parameter, every piece of geometry has to be written into the file. That takes up a ton of space.
In a direct modeling tool, the only thing that you store is the b-rep data. That takes up quite some space. In a parametric modeling tool, you don’t need to store the b-rep data, because that’s the result of the parametric history, which is stored. You can recalculate the b-rep data any time. Currently we are not storing the b-rep data, only the parametric history, that’s why the load time can take longer than before, because we re-run the entire history when you open the design.
When you merge the history, we delete the parametric history, and save the end result of the execution of the history, which is the b-rep data. This is the exact same data that we stored when Shapr did not have the hybrid parametric-direct engine. We just stored the b-rep data.
Now what we store in the underlying database of Shapr3D is completely irrelevant for the runtime performance. Eventually we’ll store the b-rep data too, because that way we can load a design faster, because we won’t need to recalculate the parametric history when you open the design.
When you export a .shapr archive, that’s a zipped snapshot of many different files and databases that make up a Shapr3D design. That being said, the archive’s size is even less relevant to the underlying file’s size which is also not relevant to anything related to performance. The .shapr archive is not the file format of Shapr3D, because we don’t really have a “file format” in the traditional sense, as the underlying representation is stored in a database and a bunch of different files, that’s why you don’t need to save your designs manually, and that’s why it’s extremely hard to lose data, because even if the application crashes, the underlying database will stay intact.
Because of this if you merge the design, you’ll end up with a similar archive size to what you’d have in the old version with the same design. The “pure” parametric archives will be smaller, because they don’t have the geometry baked into it. This will change at some point of time, and we’ll save the geometry in the database, to decrease load times. Then the archive’s size will be bigger.