Re: EDS database speed questions
- Posted by DerekParnell (admin) Aug 24, 2008
- 1195 views
With 2.2 million, EDS needs to do a maximum of 45 disk seeks to find any record. This is on par with B-Tree accessing.
Compression on a 67 element sequence is negligible. But I'll consider an option to have a non-compressed D/B for a future EDS enhancement.
Is it possible for you to split the table into sub-tables? For example, if the keys alway began with a letter, you could have 26 sub-tables (approx 85,000 per table) using 35 disk seeks in the worst case. This would average out at around 75% of the original speed.
Version 4 EDS has a number of speed improvements, but I haven't benchmarked them yet as I have one or two more things to improve. One of these is an option to load an EDS database in to RAM to avoid the disk I/O overhead. Would work better for a READ-ONLY database, but it is not going to be restricted to that.
If RAM is not a constraint, you could load the DB into a map. In your case you would need approximately 650Meg of RAM to hold the map. This would improve D/B access by at least 20 times, but you'd have to benchmark it to be sure.
