Sparse and Dense Hair Relationship
If you are familiar with the process of mesh skinning this should come easy to you. When you skin a mesh you perform a control transfer. Bones in CG have one basic purpose- to make animation of final mesh more manageable. Furthermore by constraining bone length, rotation angles, and possible transformations you allow yourself to discreticize an arbitrarily complex mesh into a simple skeleton. Note also that you can control more complex bones by a set of simple, lower detail bones.
Same concept applies to Ornatrix hair except that bones are replaced by guides, mesh is replaced by hair, and the process of skinning is performed for you automatically at the same time as hair is generated around the guides to fill in the volume in between them. Your CG application does not usually store animation information for every vertex in your mesh because it would be a big strain on memory resources and is very much unneeded. Instead only bone transformations are stored and once the pipeline gets evaluated at every frame the dense mesh vertices are updated one by one based on the transformations of bones that they are assigned to. Ox follows the same trend by only storing guide animation and letting the higher objects in the dependency hierarchy inherit this information indirectly (word indirectly is used to point out that modifiers do the transfer in any way they desire).
Animation, however, is only a small part of information that guides can represent. Ox allows user or software to add per-vertex or per-root data to every guide which can be used in any way desired, but is usually used as channel data to control specific Ox-related modifier values. Like animation if this data was copied for every strand of the dense hair model RAM usage would be very high. Therefore these channels are inherited by hair. Each individual strand simply borrows vertex data from the guide that it is associated with. Likewise selection, hide, and freeze info is also borrowed from guides and hair never has to be concerned about storing it.
Knowing this really helps when setting up a hair dependency stack/graph. The best rule to follow is to keep all of the non-parametric info as low in the stack as possible. Any information that can be modified by hand in either edit guides or another modifier can be considered non-parametric and usually takes up the most space. Channels are a perfect example of this. Therefore when dealing with channels, if you have multiple guides of different resolutions set up it is best to have edit guides right above the initial guide state converter. If you choose to add more channels later on in the pipeline do so as easy as possible. All this comes with one exception- the strand detail modifier.
Another good rule to follow is to make sure that your detail only grows in the dependency stack. For example, you may start with low detail guides with 2-segments per strand approximation. Then you may edit those guides, add strand detail modifier to increase guide approximation, and edit them some more. Once that is done hair from guides modifier can be added to finish the pipeline. However, what if you decided to add another strand detail modifier that decreases the guide approximation? That would mean that Ox would have to do same job of increasing/decreasing approximation twice, and although sometimes this is required it isn't generally a good idea for minimizing CPU time. If you do have to do that at some stage then make sure you have no channels attached to guides while you're changing the strand detail.
Changing detail in the pipeline results in all of the channel info to be changed/interpolated as well. That can be a big waste of CPU time and data can be lost since decreasing strand detail will also decrease channel detail. Best idea is to add/modify channels after you are done with strand detail modification.
It is easy to see which modifier in the pipeline is bottlenecking the hair creation process. Simply turn off and on some of the modifiers and see the response time of the whole stack. Usually the most time is taken up by state converters and approximation modifiers such as the strand detail modifier, therefore minimizing their number in the pipeline can help reduce computation speed significantly. If you do have multiple strand detail modifiers you may collapse the stack right before the last one. When you are done editing your guides completely it is a good idea to collapse the stack again and only leave parametric modifiers actually required for rendering and animation (i.e. dynamics, skinning, and others).