| BTree | |||||
| Home | BTree Guide | BTree Performance | Sample Applications | BTree Roadmap | Other Products |
BTree PerformanceThe BTree classes are very efficient. The table below shows the times taken (in milliseconds) for the standard test (description of standard test follows table) on a Pentium 4 1.8GHz with 512Mb RAM running Windows 2000. ACCOUNT_BLOGGS_ANNE
These are represented in the file as -
+ACCOUNT_BLOGGS_ANNE
Where the ASCII value of the character at + indicates the number of common characters
shared with the previous record (up to a maximum of 255). If + is 0 then
there is no compression. The first index record in a page is never compressed.
Compression introduces an overhead to the manipulation of data in the BTree
but shows definite advantages in very large trees where there is sufficient
commonality of index prefix to allow a reduction in the number of index
levels and hence access time. It also allows the programmer to provide
sensible keys to the data without worrying unneccessarily about the space
overhead.
Type
Smalltalk Express
Dolphin Smalltalk 2.1
IBM VisualAge for Smalltalk 5.0
IBM Visual Age for Java 4.0
Sun JDK 1.4.0
Addition
1.78
1.45
0.29
1.19
0.57
Deletion
1.84
1.49
0.34
1.13
0.61
Fetch
0.71
0.58
0.12
0.63
0.39
The standard
test consists of 10000 random additions of entries with an average index
length of 30 characters and an average data length of 52 characters. This
is then followed by a further 20000 random operations divided randomly
and roughly equally among additions, deletions and fetches.
Cacheing
By allowing
the index and data pages to be cached you can considerably
improve the performance of the Btrees. The following table shows the results
of the above test if all the index and data pages in the BTree are cached.
Type
Smalltalk Express
Dolphin Smalltalk 2.1
IBM VisualAge for Smalltalk 5.0
IBM Visual Age for Java 4.0
Sun JDK 1.4.0
Addition
0.68
0.76
0.16
0.48
0.08
Deletion
0.64
0.73
0.25
0.30
0.06
Fetch
0.24
0.15
0.07
0.15
0.04
Key
Compression
Further
space efficiency is provided by compressing the keys. A number of algorithms
are available to do this depending on the nature of the keys. The method
used here is to substitute the common key prefix in subsequent keys e.g.
if you have three keys in the one block -
ACCOUNT_BLOGGS_JOE
ACCOUNT_BLOGGS_JOE JR
+JOE
+ JR