Leaderboard

To goal is to recreate StarControl II Super-melee, implemented entirely in LabVIEW (except some drawing and other gfx trickery). Long way to go but gotta start somewhere.Video is of the work I did several years ago before two babies arrived. LabMelee 2017_11_11 21_59_15.mp4

So I did a quick run, and I probably need to state that the above methods cannot really be compared apples to apples. Partially for the following reasons: Some methods only support one element at a time input. If you need to enter 1000 pts at once these methods will probably be slower and involve more operations. Some methods like the circular buffer are much more useful in certain situations like where the buffer is needed in different loops or are acquired at different rates. here are numbers for single point(one element at a time) inputs: How long does it take to process 10000 input samples with a buffer size of 1000 on my computer?: Taylorh140 => 8.28579 ms infinitenothing => 2.99063 ms (looks like shifting wins) Data Queue Pt-by-pt => 9.03695 ms (I expected that this would beat mine) hooovahh Circular Buffer => 8.7936 ms (Nearly as good as mine and uses DVR) I would consider all these to be winners, except maybe the Data Queue pt-by-pt (but it is available by default which gives it a slight edge), Perhaps ill have to do another test where inputs are more than one sample. Note: if you want to try the source you'll need the circular buffer xnodes installed. buffer.zip

I've never done performance testing but I've always used rotate and replace to avoid the build array. It should be very easy to make a malleable VI out of it to further reduce block diagram clutter. For example:

So attached is my first attempt. I did things a little different than you described. For any one set of font settings I didn't generate the size of each printable character. I only get the size of each character in the string and cached the result. If that character for that set of settings was already generated it uses it. At the moment it only supports Left to Right text, without offsets (unlike the normal method) but that could be added. Also I included a test VI which after you run it a few times clearly generates text that is always faster than the built in method for a set of random strings. If you open up the font range obviously it is less likely to have a cached value for your characters and will take longer. Also my test runs the cached code twice, in the hopes I could see the difference when some text hasn't been cached but when you run it with 1000 random strings of random sizes it becomes noise quickly. Get Text Rect Cached.zip