Slow performance using String Subset?

[Oldbhoy]

Hi all,

I'm writing some code to allow elements of a picture to be added, removed or manipulated in an interactive way, based on the user's mouse clicks on the picture.

The inspiration for doing this came from Norm Kirschner's post on the lavag forums here (video links in 6th post from top): https://lavag.org/topic/17138-2d-picture-translation-movement/ 

The most process intensive function involves clicking the picture and dragging the mouse cursor to create a dashed box (region of interest). This then highlights grid squares on the picture. While this works fine, it slows down as more grid squares are selected. This makes sense with how i've written the code, but what I found unusual was that i'm getting a big performance hit in the subVI responsible for finding the opcode associated with a particular picture element (see VI snippet attached)

The VI above this flattens the picture to a string, which is the picture data in.

The string with the picture data is then split using a predefined offset for the picture element of interest. 3 strings then emerge: the portion of data before the element of interest, the element itself, then everything after it. The element of interest can be changed or removed as required, and the 3 strings concatenated to rebuild the image

What i noticed when running VI profile and performance was that the attached subVI seems to take a relatively long time to run (on average about 3ms). For just a few string subset calls and a couple of typecasts this seemed quite long. Perhaps i'm being naive and this is fast, but essentially this results in a huge chunk of the total processing time and slows the code down noticeably when multiple elements are selected

Does anyone know of a quicker way to parse the picture data string than using String subset calls in this way?

Any help would be greatly appreciated

[thols]

Are those strings very long? What about using an U8-array instead?

[Oldbhoy]

Hi Thols,

Yes, the strings are long, but string length doesnt seem to influence performance much at all. A test string of 100 bytes performs much the same as passing a large image that's several hundred KB

[thols]

Well, if I run your attached code with some different strings I get about 1-7 microseconds. I know performance measuring can be tricky, but there is probably some other issue. Have you tried creating an exe of it too see what happens? Could you attach the complete code?

[Oldbhoy · Accepted solution]

thols, you were absolutely right, it was a separate issue which i think i've figured out now thanks to this thread

As it transpires, i was getting about 16microseconds on my laptop to run the subVI i originally linked, and Draw (which confused me) took up the remainder.

The reason for the slow update to start with was that I'm using a queued msg handler to respond to "mouse move+mouse down" events, which trigger the rectangle drawing on the picture. This was then just queuing up elements eventually much faster than the code could execute them, hence a slowing over time.

Adding a <has x ms elapsed> boolean check into the event structure handling the UI queue for this event eliminates the problem