Member 10097972 wrote:VBc and C/C++ for embedded device, and a tiny bit of VC++.
Perhaps the rest of the comments are based on that background.
Certainly for me (decades ago) working on computers with much smaller memories one had to be much, much more careful not only with how memory was used but how and when it was allocated.
Computers have substantially more memory than almost all embedded devices. That was even true long ago. Both have gotten bigger since then.
Additionally for PC computers the OS and compilers/interpreters have been designed for decades to optimize the usage of that memory.
One need only read up on how memory heaps used to work (perhaps even how they are still taught) versus the complexity that goes into moderns heaps to see the changes. And even reading up on how the OS and even the CPUs are optimized to assist in that. Even physical memory and other hardware in computers has changed to facilitate that.
Member 10097972 wrote:So this function is always running in it's own thread...
Excluding the VB part of that...
Yep that is how you write it - in its own thread. Unclear to me why you seem to think that is a problem?
Member 10097972 wrote:This is used to prevent multiple instances of it running,
Not sure what that is supposed to mean. But any IP port should never have more than one reader. Not in any circumstance. So mentioning seems odd since that is exactly what must happen.
Member 10097972 wrote:the compiler isn't THAT smart is it?...I would have done the DIM's above the loops
I think this is your major concern.
And yes the compiler (and interpreter in this case) is that smart.
The code I see is getting a message, in a buffer, but still a message. So the API creates the buffer and not the code that you posted. You definitely could not have moved that outside the loop. (As mentioned compiler/interpreter will easily deal with this.)
So I don't see any other allocations in the loop?