ShaunR

Me too

@JG Well. Both functions of yours are much faster than on my machine. Not running on a quad core are you? (it does use parallelism). Yes I have optimised the order. But for the purposes of your tests; I moved the space char to be the last. But in my tests (poor lowly Dual core) it made no difference whether it was in the first frame or last. The original was about 10ms faster, but since your tests are 100 ms faster than mine anyway;that's about a gnats fart It's interesting to note that in both our cases, the native LV function is pretty similar. Again I'm coming back to parallelism since the regex functions only use the UI thread (if I remember correctly). Note that I don't have the openG libs installed so the old one is disabled (hence zero) Still waiting to see the performance improvements in 2011...lol. @JK. The main advantage of this method (over and above just being faster than the in-built function) is that it is very robust in terms of the length of the string (very similar times for a short string of say 10 chars and one of ..say 10,000 chars-all beginning and end white spaces being equal). Performance is dictated by the number of white spaces only, unlike the other methods that need to iterate over the entire string.

@ JG Why have you slowed it down? (those arrays were inside the for loops for a reason ) @JK. You are right. The original Trim Whitespace+.vi (thanks for pointing out the two chars I missed JG-are they considered whitespace?) was a direct replacement for the built in Trim [whitespace] function. However. the Fast Trim was more useful on comms strings (especially serial) where you can have all sorts of non-printable chars and not just "whitespace".

JG always looks like that

Use the system tab rather than the Labview one. It has the method to create them on-the-fly (if I remeber correctly).

Try unchecking "Remove Polymorphic Instances" and verify that you have no broken VIs in disabled structures.

This is a real pain and gives no indication whatsoever where to look. You get it after building an application exe that works fine in the IDE and usually find that a diagram disable structure somewhere isn't doing what it says on the tin.

Making optical fibres listen.

That's sweet. I'm not a great fan of the app builder API either. At what point does the build.vi get executed? Is it run whenever you create a new project? (wasn't clear from the video which I had to scroll around to see...lol)

My point is that you shouldn't have to pay for stability and upgrading to a new version is not a bug fix, it is a project risk.

Paying for bug fixes by being forced to upgrade has always been my major criticism of NI (what about my 2010 and 2009 installations?). I would also question if many of the speed improvements are really much faster than 2009. 2010, yes. That was a slug. But compared to 2009? Maybe in some circumstances (FPGA?), but I haven't seen many yet. Personally, now I have had a chance to play with it, I don't think there is much in it from a user experience point of view. From an execution view point, I have seen 1 instance where 2011 x32 was faster and 2011 x64 was slower than 2009 and all the rest about the same for identical code. I have already commented previously that 2010 was about 3x slower at compiling, loading and saving than 2009 so when the "selling" point is speed and stability. Is it worth paying thousands for a more stable 2009? (Well. It is since, the bugs in 2009 won't get fixed ) If you ask me (I know your not...but I'll pretend anyway ). One of the biggest improvements that I would have paid a ton of gold for (in recent history) was never a major selling point.- 32 AND 64 bit compilers. Although I can still find something to moan about with those too

Adam Curtis

Improved Stability I would be very interested to see a similar graph for CARs raised by customers for the different versions.

Well. If they have difficulty with DLLs (SOs on linux) then kernel level drivers will slay them. The randrive.sys driver is no longer available in windows 7 (hope they weren't thinking of using it ) but there are a few 3rd party solutions I think. One final thought. Turn off the nagle algo. It is known to play hell with things like games and it is known to silently introduce delays in packet sending through the loopback. It is off for my setups for this very reason, although I never saw 2 second delays.

Windows 7 x64 with LV 2009 x64. Indeed. My problem was just sheer throughput and it didn't matter what it was written in. I know it's curing the symptom rather than the problem (and it will be blocking), but have you tried getting the C read and write stuff compiled into a DLL and using that instead? Just a thought to see if the specific problem goes away. What do NI say about it (after all it is repeatable by a number of people)?

Hmm. Yes. A bit of a trend apart from LV2010. And it may be why I cannot see any problems on my machines (none of the examples fall over after running for 29 hrs now ). My windows TCPIP is highly modified from a standard install. It was the only way i could "reliably" get TCPIP transfer rates of up to 80 MB/sec. (Not in loop back; across the network). The sorts of things that were changed were the TCPIP auto-tuning, and Chimney Offload. Also had to play with the TCPIP Optimiser, but can't remember exactly what now. This was in addition to the TX buffers. But i wouldn't have thought 25MB/sec would/should be that much of a problem, but I guess it is windows eh?

I know it's one of those silly questions (especially since the C program would suffer from it too). But has to be asked..... Are you sure the power saving is turned off on the network card(s)

Hmmm...... Wait for SP1

Try it this way....

List of bug fixes in LV 2011

New crash reporter But it definitely feels more responsive than 2010.

I guess it won't help then. Rolfs got a point, but immediate really puts a burden on the CPU since you've got to (wo)man handle characters as they arrive. Then concatenate and terminate the loop on whatever it's supposed to terminate on (number of bytes or term char). This is the sort of thing: As you can probably see from the snippet. there is a (small) possibility that the first 4 bytes are garbage or maybe you read 1/2 way through a string and therefore expect a huge number. So are you using character terminated or pretending a payload size? You haven't said much of the inner workings. Example perhaps?

Well, that's not a huge amount. Even the default LV examples should be able to cope with that. The default windows buffer is 8192 (if I remember correctly-don't have the getsockettoption....maybe later in the week). There are a few ways of calculating the optimum size dependent on the network characteristics, but I usually just set it to 65356 (64K) unless it's a particularly slow network (like dial up). It really makes a difference with UDP rather than TCP (datagram size errors). Note, however, that it only makes a difference if you are setting the "Listener" connection. It has no effect on "Open". It''s strange that the C program doesn't exhibit the same problem. If you are doing the usual write size, write data then you can try and combine it into one write operation (just concatenate the strings) but I haven't run into a problem with the former. If you have the C code then you can take a peek to see if they are doing anything fancy with the sockets....but I doubt it. Are you trying to send and receive on the same port? (Cmd-Resp) or do you have two separate channels; one for sending and one for receiving. If the latter. What part disconnects? The receipt of the data or the send of the data (or arbitrarily both) and what is the error thrown (66?). If you get timeout errors on a read, then you should see that in the network monitor (task manger) as drops but you say that it "lopes" (had to look that one up..lol). That's normally indicative of a terminated messaging scheme where the terminator gets dropped for some reason..

What sort of throughput are you trying to achieve? You could try and give LV a bit more time to service the TCPIP stack by increasing the buffer size.

Ooooh. You like living dangerously eh? .