Benchmark the graph speed on PDAs

[Bob_Y.]

I was not offended in any way.  I was merely stating that  there are plenty of variables as to why it could be less than ideal or even less than expected. 

Are there any debugging and performance enhancing techniques (besides little blue pills) that would be usefull in working with PDA applications?  I am very experienced with LabVIEW but very fresh to the world of PDAs so any hints and tips would be helpfull.

Thanks,

Bob Young

[EdDickens]

Here's something unexpected.

I just installed all the LV 8 PDA stuff with the MS tools. On my Axim X51, which is similar to Bob's but with a 424MHz processor and QVGA graphics with no dedicated accelerator also with Windows Mobile 5, your test app runs consistantly at 850-900 ms.

Not sure what to make of it now.

I did notice in the build specs in LV 8 that you can set the front panel bit depth. I could choose between 8, 16 and 24. It runs fastest on 16 which is the native depth for my PDA. Maybe that has something to do with it. Bob is going to rebuilding his at 24 bit.

Ed

Message Edited by Ed Dickens on 12-21-2005 03:07 PM

[tst]

The general advice for improving performance in LV PDA is to make things as flat as possible - don't use subVIs and nested structures. This is important because the PDA seems to be much less better at handling these things than a PC with the same specs would have been.

[EdDickens]

I just installed the 7.1 PDA module to compare.

With 7.1 it runs at about a 2 second average. A little bit more than twice as slow compared to the 8.0 runs of 850-900ms.

Still wondering.

[EdDickens]

OK, here's one more test.

I thought I'd try optimizing the VI a bit to see what can be done. It looks like having no subVIs on PDA is a good thing.

My Dell Axim X51 can run this "flat" version in 25-30ms.

Ed

Message Edited by Ed Dickens on 12-22-2005 03:09 PM

[EdDickens]

Since the first one I posted is LabVIEW 8.0, here's the same thing in 7.1.

I get the same results. 25-30ms

Ed

[chilly_charly]

This is a nice work Ed ! You could twick the code and optimize further, suppressing a double cluster inversion...

Message Edité par chilly charly le 12-23-2005 03:09 AM

[EdDickens]

---

@chilly charly wrote:

You could twick the code and optimize further, suppressing a double cluster inversion...

---

So it sounded like a good challenge.

The attached versions both run at 3-4ms on average. But his may be cheating a bit because the only part that being timed is the drawing of the lines. I moved all the code that builds the picture information outside into the same loop that generates the random numbers. But, this is truely timing the drawing speed of the device. The other versions are probably more practicle for real use. Before I came up with this, I had a couple versions that built the picture info inside the drawing loop that were running at 10-15ms. Maybe I'll remake those and post them.

I tried another version where everything was done in a single loop, but that slowed it down to about 20ms. I thought that would be a bit faster, or at least as fast because it wasn't building an array, then unbuilding it to draw the lines.

Ed

Message Edited by Ed Dickens on 12-23-2005 09:34 AM

[chilly_charly]

Nice work Ed !

I arrived at the same conclusion. The limiting rate is neither the line drawing, nor the subvi overhead, it's the way the picture string is built. So the "problem" was on the LabVIEW side.

I have started to rewrite the demo picture control (in the example directory), and of course I now get a much better result. Attached is my provisionnal version. I have a few more ideas.

Unfortunately, my home internet connection is again very unstable, so I can maintain connection for a few seconds only.

I hope I'll be able to stay in touch !..

[chilly_charly]

Nice work Ed !

I arrived at the same conclusion. The limiting rate is neither the line drawing, nor the subvi overhead, it's the way the picture string is built. So the "problem" was on the LabVIEW side.

I have started to rewrite the demo picture control (in the example directory), and of course I now get a much better result. Attached is my provisionnal version. I have a few more ideas.

Unfortunately, my home internet connection is again very unstable, so I can maintain connection for a few seconds only.

I hope I'll be able to stay in touch !..