I am debugging performance of usd stage and noticed that even on very simple stage some processes are always cooked twice or more, especially primitive pattern evaluation tends to cook more than once.
Those entries inside the cook methods for a LOP node are tracking very low level operations, and so may capture things that aren't obvious when viewing from a higher level. So in the sublayer case, adding a sublayer to a LOP stage requires that the stage be "locked", then "unlocked" (so the sublayer can be safely added to the stage), then "locked" again. The "unlock" and second "lock" are implementation details of the "add sublayer" API, and the fact that these are captured by the performance monitor is a side effect that isn't worth worrying about. Same for the prim pattern evaluation. Your pattern isn't actually being evaluated twice.
What would be the best way to confirm that operations are not being evaluated multiple times? I have some patterns in Performance Monitor that have 4 or 8 cook counts and I am not sure I should be worried about any of those and how much I can actually further optimize.
There are definitely cases for some LOP nodes where cooking the node may involve evaluating a bunch of patterns. Or evaluating the same pattern multiple times. Or evaluating internal patterns which may not even be specified by the user. These different "types" of pattern evaluations can't be separated out. I would say don't worry about the "Count" values as long as the overall performance seems reasonable. And even if the performance is too slow, the "Count" is not something you can control, so just approach the problems you can address such as simplifying your patterns. One good way to do this (if you simply cannot make your pattern evaluation fast enough) is to create a collection from your pattern evaluation, then nodes downstream can just use the collection rather than re-evaluating the expensive pattern.
