Reply to thread

Message

ok, one of my iprovement ideas was the following:
Currently, when we read data from the database, we use the generic IDataReader's GetValue(int colIndex) method and we cast the resulting object to the type we expect. system.data.sqlite's SQLiteDataReader, however, has native methods for different data types, such as GetBytes, GetGuid, GetString, etc., which directly return the desired type.
What I tried now is to use these native methods at least for byte[] values (in particular images, because they are huge in size) and Guid values (because we use them very often). The other values were for simplification purposes still read with GetValue. Result as follows:

locking_mode=Exclusive / Shared Cache / Page Size 4KB / Discarded the respective first result / Use non-generic read methods of SQLiteDataReader for byte[] fields and Guids
ReadTest 1: 11746ms, 12001ms (23747ms)
ReadTest 2: 214ms, 219ms (433ms)
ReadTest 3: 10.2ms, 5.9ms (16.1ms)
ReadTest 4: 44.1ms, 44.6ms (88.7ms)

The result is that according to the +/- 10% definition above, ReadTests 1, 2 and 4 are about the same speed, ReadTest 3 is even slower (although I would bet this is coincidence again when you look at the two results of the two test passes. The discarded first result of ReadTest 3 was 8.2ms by the way so no idea why the second pass was slower...)

Anyway - this doesn't seem the right direction. Back to square one...

<blockquote data-quote="MJGraf" data-source="post: 1036202" data-attributes="member: 17886">ok, one of my iprovement ideas was the following:Currently, when we read data from the database, we use the generic IDataReader's GetValue(int colIndex) method and we cast the resulting object to the type we expect. system.data.sqlite's SQLiteDataReader, however, has native methods for different data types, such as GetBytes, GetGuid, GetString, etc., which directly return the desired type.What I tried now is to use these native methods at least for byte[] values (in particular images, because they are huge in size) and Guid values (because we use them very often). The other values were for simplification purposes still read with GetValue. Result as follows:locking_mode=Exclusive / Shared Cache / Page Size 4KB / Discarded the respective first result / Use non-generic read methods of SQLiteDataReader for byte[] fields and GuidsReadTest 1: 11746ms, 12001ms (23747ms)ReadTest 2: 214ms, 219ms (433ms)ReadTest 3: 10.2ms, 5.9ms (16.1ms)ReadTest 4: 44.1ms, 44.6ms (88.7ms)The result is that according to the +/- 10% definition above, ReadTests 1, 2 and 4 are about the same speed, ReadTest 3 is even slower (although I would bet this is coincidence again when you look at the two results of the two test passes. The discarded first result of ReadTest 3 was 8.2ms by the way so no idea why the second pass was slower...)Anyway - this doesn't seem the right direction. Back to square one...</blockquote>

[QUOTE="MJGraf, post: 1036202, member: 17886"] ok, one of my iprovement ideas was the following: Currently, when we read data from the database, we use the generic IDataReader's GetValue(int colIndex) method and we cast the resulting object to the type we expect. system.data.sqlite's SQLiteDataReader, however, has native methods for different data types, such as GetBytes, GetGuid, GetString, etc., which directly return the desired type. What I tried now is to use these native methods at least for byte[] values (in particular images, because they are huge in size) and Guid values (because we use them very often). The other values were for simplification purposes still read with GetValue. Result as follows: [B]locking_mode=Exclusive / Shared Cache / Page Size 4KB / Discarded the respective first result / Use non-generic read methods of SQLiteDataReader for byte[] fields and Guids[/B] ReadTest 1: 11746ms, 12001ms ([B]23747ms[/B]) ReadTest 2: 214ms, 219ms ([B]433ms[/B]) ReadTest 3: 10.2ms, 5.9ms ([B]16.1ms[/B]) ReadTest 4: 44.1ms, 44.6ms ([B]88.7ms[/B]) The result is that according to the +/- 10% definition above, ReadTests 1, 2 and 4 are about the same speed, ReadTest 3 is even slower (although I would bet this is coincidence again when you look at the two results of the two test passes. The discarded first result of ReadTest 3 was 8.2ms by the way so no idea why the second pass was slower...) Anyway - this doesn't seem the right direction. Back to square one... [/QUOTE]