Sample: BlastFile with 1 to 10.000 result items
| Mode | 1 | 10 | 100 | 1000 | 10000 |
|---|---|---|---|---|---|
| flex | 0.003 | 0.015 | 0.199 | 1.979 | 25.548 |
| flex-tcl | 0.005 | 0.018 | 0.167 | 1.775 | 20.701 |
| gcj | 0.099 | 0.149 | 0.784 | 7.536 | 83.421 |
| gij | 0.109 | 0.482 | 4.917 | 51.939 | nd |
| java | 0.228 | 0.348 | 0.753 | 3.048 | 27.806 |
| javaip | 0.180 | 0.517 | 4.715 | 49.852 | nd |
| plex | 0.011 | 0.082 | 0.856 | 9.565 | 107.987 |
| perl | 0.031 | 0.050 | 0.235 | 2.280 | 23.916 |
| re2c | 0.004 | 0.012 | 0.076 | 0.765 | 8.438 |
| tcl | 1.702 | 12.524 | 140.249 | nd | nd |
The Re2c based scanner is the fastest, but the setup and the coding is more complicated than for the other scanners.
Flex-based scanners are 2-3 times slower than Re2c based scanners, regardless if there is an embedded Tcl-interpreter for better string handling (flex-tcl), Jflex code (java), executed with the Sun-Java Hotspot virtual machine (1.5) as well as to machine code compiled Jflex code (java-gcj) and Plex (sbs-plex = Pascal lex) based scanners are about 5 and 10 times slower than Re2c based scanners. Interpreted Java-Code either executed with the Sun-interpreter (java-ip = “java -Xint”) or with the gnu-interpreter (java-gij) is about 50 times slower than Re2c-Code. The Tcl based scanner is about 1000 times slower than the Re2c based. The per scanner is a line based scanner thereof not able to do complicated scanning with more than two states or patterns on the same line.

No comments yet
Comments feed for this article