The health scores are based off of the instructions that are generated for each individual CacheIROp in a stub. More costly instructions, such a callVM, will contribute a higher score compared to other instructions. Stubs that are generating costly instructions will have a higher total stub score and will make it clear, for debugging purposes, which stubs need to be fixed because of the types of Ops that are being generated.
The prototype is a shell function that can be called with or without arguments, you may pass a function and have the associated script rated or call the shell function without parameters and have the current script rated. Unless you are calling the shell function there is currently no associated cost. Moving forward I will be creating an interactive UI to further inspect the stubs, which well hopefully provide an even easier way to diagnose problematic stubs. This will be done by using the structured spewer to output in JSON format.
As for what this tool is meant to expose, its intended use case is for aiding in the ability to see when the we are generating CacheIR stubs where the ops in the stubs are costly. This will make it so we can see the JSOp we are generating stubs for, the CacheIR stub chain and information about that stub, the CacheIR ops (will be added with inspection tool), and the total cost of these ops in terms of their generated instructions. With all of this information, mainly the stub hit counts and the health score, we can see which stubs are problematic and go in and fix the CacheIR generated for these cases.