I would like to know which of the two “is faster” to read and write the data in memory: structure or dictionary?
Why this question?
I need to enter data and read data every second. The processor is already exhausted for another application, so I would like not to burden the CPU further.
Also I like the speed 
Thanks.
Could you give us an example of how you intend to use either? A structure and Dictionary don’t serve the same function, so it’s hard to imagine.
My application timer, every second reads a file.
The file is a single row, but using Split () I insert the 50 data into an array string (and in the future even more, but I don’t know how many to date).
However, the 50 data are FIXED for the entire life cycle of the application. They cannot be added by the user (ie they cannot be added or deleted at runtime). If 50 is, 50 remains forever.
Then there are 4 functions that, within that second, must access this data: manipulate it with mathematical calculations, and return the result for the different uses.
I hope I’ve been exhaustive.
So far. Where would, for example, the Dictionary come into play? To store the different calculations?
I would use a sqlite database… in memory if it is not meant to be saved between sessions.
It sounds strange, but I thought of the dictionary to have a key and save / read the data without making a mistake. When the 4 functions have to take the data and when they have to rewrite it. Between them … the manipulated data is turned over.
But the structure also uses a key, so I was wondering if the structure is faster (which I think).
I know it can be done, but I don’t think that’s the case.
I’m sorry, I’m still not following. If you just want to read the array from the file once, just put the array someplace you can access it from wherever it needs to be accessed. If it needs to be available application-wide, for example, create an array property in App and fill it on App.Open. (This is just one way to approach it.) I’m not sure where or why you’d need a key.
A stupid example. Is it easier to go wrong with Dictionary or with an array?
dicDataRefSim.Value ("PLANE HEADING MAGNETIC DEGREES") = aFunction (dicDataRefSim.Value ("PLANE HEADING DEGREES TRUE") =)
If dicDataRefSim.Value ("PLANE HEADING MAGNETIC DEGREES") = something Then
...
else
...
And an array()
anArray (2) = aFunction (anArray (13))
If anArray (2) = something Then
...
else
...
and the structure is similar to the dictionary. And I was wondering if the structure is faster than the dictionary.
That’s all.
PS: the data are certainly not 3, but at least 50. And I can’t break my head… chasing the numbers in the function lines and between the functions … I’m a human, so I’m subject to mistakes.
If you need to label your data, use the Dictionary. If you don’t, use an array as it will be faster.
You can use a Structure as an array, but even if it was faster, you can’t change its dimensions on the fly.
You can also use a MemoryBlock, but I doubt you’d get much of a boost over an array, and it will hurt code readability.
Use the array and create global constants to refer to the indexes.
anArray(PLANE_HEADING_MAGNETIC_DEGREES) = aFunction(anArray(PLANE_HEADING_DEGREES_TRUE))
if anArray(PLANE_HEADING_MAGNETIC_DEGREES) = something Then
While you can’t resize an array in a structure, you can have can array of structures, which would be resizable, and might be useful if each record had multiple fields for readability.
I suspect (but could be wrong) that it would be faster and have less of a memory footprint than an array of classes.
One other trick is using a memoryblock with a structure overlay using offsets making it like an array of structures … Norm wrote a blog post using that technique for a different purpose.
https://www.great-white-software.com/blog/2019/07/16/c-unions/
The handy thing about having data in a memoryblock is that if needed, it makes saving the data as simple as saving a string.
-Karen
For 50 elements the access speed really doesn’t matter. If you have 50k elements then you can do something elaborate like using an SQLite database.
ok, thanks everyone for the answers.