Stub out Error Cluster from Error Code.vi?

Question

When I profile my application, I find that the biggest consumer of CPU time is the Error Cluster from Error Code.vi, called from a number of locked NI libraries.  How can I stub out this .vi, replacing it with basically a pass-through?  I tried creating a project specific .vi with the same name, and when I open my project all the project and vi.lib .vis used link to it, but they all come up broken and have to be re-linked, which I can't do in the locked .vis (I matched the ins and outs and connector pattern).  I can't edit the Error Cluster...vi directly, getting a message about the .vi being used by another application even with a clean start of LV and going directly to that .vi in the library (and I would prefer to not mess with the vi.lib version anyway).  Any suggestions?  Thanks.  LV 2011.
Matt

Answer 1

If you have the LLB manager open it reserves your VI in a different appliation instance, therefore it is locked and no editing.  Simply close the LLB manager and you can whack away at that VI.
I doubt that the shared clone setting plays much of a role here, there are some deeper issues.   A rather amusing VI in a few ways:
In order to show the VI Title instead of the Name you Open a VI reference which is going to stick you into the root loop.  10 reentrent clones simply means 10 copies waiting in line for the root loop.  A non-reentrent version would simply have 10 copies waiting to run.  Minus the root loop issue, reentrency is the way to go, and on a desktop machine shared clones is typically quite effective.
It can't be a slow VI, look Trim Whitespace was inlined manually to avoid a performance hit!  In a loop maybe, but really, shaving off the overhead of a single subVI?  That's optimization.
But wait, all of that and much, much more is given right back by the use of Delete From Array to remove the first element of the Array.  Bad on so many levels.    Delete From Array is a data copy machine, and now you are doing one needlessly.  Array subset is your friend here, tells the compiler you are only reading, nothing to get excited about. Pull it outside the case structure, you are ditching the first element twice in the two branches.
Concatenating strings in a loop, also a recipe for fun.  Often there are ways to leverage Array to Spreadsheet string for better performance, or build a string array and then concatenate at the end.  Probably not a big deal here, how big are call chains really, but if you are inlining subVIs by hand then you should really be frying the bigger fish.
I find myself in your shoes fairly often.  Some clunker in vi.lib causes a bug or sluggish performance.  You either ditch the NI code and roll your own, or make it work on your machine but not others, or chalk it up to the cost of doing business.  I have tried on numerous occasions to suggest that all patches to vi.lib be made readily and freely available to all previous versions of LV that are compatible.  Let's say this VI got tweaked so it was a bit more performant for you, at least enough to be viable.  Then you could happily use the patched version in LV11, and if you went to a different machine you would simply make sure vi.lib was up-to-date.  These types of patches could roll out incrementally as needed, less need to cross your fingers that you won the CAR lottery with each new version of LV.  (I guess most lottery winners don't shell out $$$ to collect their "winnings" though).
After all that what would I do here?  I would wrap that sucker inside a disable structure (provide minimal functionality, like pass through caller name, code and error instead).  Then I would check the performance again.  Now you have a data point as to whether or not it is worth it to proceed.