Actually these shown test aren't so useful because they are poorly implemented. What is wrong with them?
- When testing WRITE performance of classes/objects the above tests measure both the creation time and first write to fields together. This of course does not provide real picture. Why? Because most of the measured time is actually spent in class creation. You see the main drawback of classes versus records is the fact that their creations takes longer time than record creation. Why is that.
Because when creating class you don't just allocate memory for it like with records but you also execute some special initialization code that is required for classes.
Now if you would split the test to measure class creation and field writing times separately you would see that writing to class fields isn't much slower than writing to record fields if it even is.- When testing array of records tests only perform sequential access but not random access. Sequential access to array items is faster due the fact that arrays are always stored in memory as one single memory block and becouse stem memory also excels in perform in sequential memory access. You can observe this by using some memory diagnostic and measuring utils like MemTest.
- There is no test that would measure performance of adding or removing records during run-time. Here arrays lose quite a lot of performance because when removing of items you need to rearrange all other items in order to fill the gap. This can become quite slow when you have huge number of larger records as there is quite a bit of memory that needs to be moved. Also due the fact that arrays are always stored as one continuous block of memory it means that when you are extending the size of that array there needs to be sufficient free space after the existing array for resizing. If there isn't then the contents of the whole array needs to be copied to another location in memory where there is enough free space to hold the entire extended array in one continuous block of memory.
When using lists of classes the above mentioned drawback are barely noticeable because their internal arrays only store references (pointers) to these classes so rearranging their items does not require so big memory movements. Also the data of these classes doesn't have to be stored in one continuous memory block.- Another thing that can screw up tests results is doing random number generation inside the test method/loop itself. Why? Because time taken for generating single random number can vary quite a lot. Of course it most depends on what kind of random algorithm is being used. And it can also depend on whether your CPU perhaps have built-in support for random number generation. So I strongly recommend you generate all needed random numbers before testing and then read them from memory during the testing itself.
- And finally the problem of all of the above tests is that they are to short. What do I mean with that? Today's computers are made for multitasking which means that it is not necessary that when you are performing the test your application will be given all the available processing power of CPU core. Not to mention that since most modern CPU use automatic throttling to achieve better power saving it is not necessary that the CPU is working at max speed at the time when you are performing your tests. You can observe this by starting the above test multiple times where you will see varying results.
So in order to get more accurate results it is best to make sure that the test are running for longer time or are repeated multiple times and then average time is calculated from the results.
Bookmarks