ShaunR

OK. so what am I missing?
 

Ok. first off. Windows is not a real time OS so it isn't deterministic. I know that, you know that but your project manager probably doesn't so that was for him.
 
Second. I bet you are so close, that if we can just optimise what we already have a little better, we will be home and dry. Sure. Then in 6 months the spec changes to every 7 ms and the project manager says "you did it before, now do it again - it's only 1ms". 
 
So. What is the problem?

 
Ahh. Just poking over the 8 ms in places.
 
Lets see if its what all the girls say that size does matter and bigger is better.
 

 
Ah yes. No problem with under 8ms. The girls are half wrong and half right. Size does matter but smaller is better.
(In fact it is linear. 400,000 will yeild about 3 ms, 200,000 about 1.5 ms etc).
 
Easy answer 1. Reduce the data size in the global. 
 
But why so slow? Is it the array disassembling? Is it the reading from the global? Does it need more coffee?
 

 
Oooh. Microseconds. My spidy sense tells me its the global.
 
Easy answer 2: Don't use a global for big arrays if you're time constrained.
 
 
That about wraps it up for reading.
In the next issue we will cover:  Oh my god. It all falls to crap when I write data.   

Well. you have descrete increments that luckily correlate to the index. So if your user enters 110 you can just divide by 100 (quotient) and it will give you 1 which you can pass to the index array function to extract the row.
 
The fun begins when you want to get to the closest higher or lower than the value input

There is the "Data Logging" example which demonstrates this exactly in the SQLite API for LabVIEW. The issue would be whether you could log continuously at >200Hz - maybe with the right hardware and a bit of buffering.

After just over a year, someone has claimed the first prize. The original proposer for the competition is in a bit of a quandary .
When the competition was set 5 btc was worth about $75. Now they are worth about $3000 The deadline was set for when 5 working solutions were submitted, however, there has been only one and the OP has now closed the contest.
 
Kudos to the guy who had to write native labview code to handle big numbers and eliptic curve multiplication, which is no mean feat..

Right. so that's a "no" then In an exe,paths are different from development as the executable filename is included. Additionally, you placed the DLL in the data directory and there is no appending of the data directory in your path code.
To test, replace your path code in the image with an "Application Directory.vi", append the DLL name, and make sure the dll is in the same directory as the exe. This will ensure that when you build an exe, the dll is being picked up from the application directory regardless of how paths to VIs and libs mutate.
NB:
"Application Directory.vi" gives the path to the directory in which your project file resides when in the development environment.