LabVIEW
Match Pattern Special Characters Confusion
Solved!
wiebe@CARYA wrote:
@Yamaeda wrote:
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.
It doesn't need to be an XNode.
Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community
But it's growable; and you can only do that with an XNode.
@paul_a_cardinale wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.
It doesn't need to be an XNode.
Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community
But it's growable; and you can only do that with an XNode.
As the idea explains, growable isn't always convenient. Sometimes it absolutely is.
Search LabVIEW like a graph! 
@paul_a_cardinale wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:
If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.It doesn't need to be an XNode.
Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community
But it's growable; and you can only do that with an XNode.
Everything under VI Server class "GrowableFunction" is growable, and, as far as I know, has nothing to do with XNodes.
I always wonder why NI sometimes chooses to implement functions using XNodes instead of creating proper native functions.
Are XNodes more easily modifiable, or cheaper to develop and test by NI? Also they are not inlineable, so what is the advantage?
@raphschru wrote:
@paul_a_cardinale wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:
If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.It doesn't need to be an XNode.
Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community
But it's growable; and you can only do that with an XNode.
Everything under VI Server class "GrowableFunction" is growable, and, as far as I know, has nothing to do with XNodes.
XNodes are the only thing growable that we can make.
@raphschru wrote:I always wonder why NI sometimes chooses to implement functions using XNodes instead of creating proper native functions.
Are XNodes more easily modifiable, or cheaper to develop and test by NI? Also they are not inlineable, so what is the advantage?
A function is a lot more work. Functions integrate in LabVIEW. For instance the enum to scripting new objects needs to be adjusted. But the function will also effect a few binary resources that contain all other functions. Adding a function would require a lot more testing. An XNode is just a special library that can be added like any library. The library should be tested, but it doesn't effect LabVIEW.
I don't think there's a good reason an XNode can't be used in inlined code (the xnodes themselves are inlined). XNodes are scary things, so I think it was just a save choice when inlining was introduced.
BTW there are functions that can't be inlined...
@paul_a_cardinale wrote:
cvbvc
@raphschru wrote:
@paul_a_cardinale wrote:
wiebe@CARYA wrote:
@Yamaeda wrote:
If i remember Darrens video correctly one of the arguments against Match Regular Expression was that it was an Xnode and could cause issues when compiling, apart from being noticably slower on simple tasks. Often the last part is irrelevant, but it can be good to know.It doesn't need to be an XNode.
Sometimes the XNode isn't convenient at all: Add Match Regular Expression sub VI - NI Community
But it's growable; and you can only do that with an XNode.
Everything under VI Server class "GrowableFunction" is growable, and, as far as I know, has nothing to do with XNodes.
Correct. The only commonality between GrowableFunction and XNode is that they are both under the Node class.
And they both can grow... 😋
And they are both horrible to script.
wiebe@CARYA wrote:
@bienieck wrote:
I switched to Match Pattern for simple patterns after watching some presentation from Darren N. Allegedly this function is more efficient.
For the CPU: probably.
For the programmer: not always.
A huge performance difference is caused by the difference in resulting string: Match Pattern returns SubStrings, Match Regular Expression returns Strings... Seems to me Match Regular Expression (an XNode) could be changed so it returns SubStrings too...
Not likely. That would probably require the entire algorithme being implemented in the LabVIEW manager layer, not imported as an external code source from another, non-LabVIEW aware project (PCRE). But reimplementation of the PCRE package in the LabVIEW C manager is extremely unlikely. Not only would it be an immense effort, with likely a lot of incompatible corner cases to the original PCRE quasi standard, but it would also make it extremely awkward to back port any PCRE improvements into that code. The C code dealing with subarrays has to be fully aware of the LabVIEW data type model and that is not something you can force push into any existing code.
