At first: Scidb does not use the Scid parser or any other one,
the parser is developed from the scratch (but the Scid parser
was a model).

About the speed: measuring the speed is useless as long as Scidb
is compiled with debug code, this is slowing down the parser
enormously. Later the alpha version will be built without debug
code. In my test the Scid parser is about 10% percent faster
than Scidb's, measured with an older optimized version of Scidb
(the current version of Scidb has a performance issue which will
be fixed later), but Scidb's parser is quite more complex than
Scid's (for example: supporting some variants, extracting more
information, supporting many languages).

Scidb's parser is parsing the whole game data, not only the header,
for many reasons:

1. The opening tree will not work without the information
   from the game data, and some more other functions will not
   work also.
2. Scidb is supporting some chess variants, this is not possible
   without whole game parsing.
3. Scidb's parser is checking the consistence of the game (and
   writes log info).

The Scid parser also has to scan the whole game data, so you cannot
compare the parser speed with ChessBase or ChessX. ChessBase is
only building index information, and cannot provide an opening tree,
except you are creating an accelerator file, and in sum this costs
more time than Scid or Scidb needs. Note that ChessBase is not doing
any error or consistency check. I don't know the newer parser of
ChessX, the older one was very slow.

Please note that Scidb is not designed for PGN (the same applies to
Scid), it is highly recommended to use the native database format.
The support of PGN is only an unavoidable feature. (The PGN format is
out-dated and cannot support newer database formats, like ChessBase
CBH or Scidb's SCI.). But ChessX is especially designed for PGN, and
is not supporting any other format.

The decision for a parser algorithm depends on the functionality of
the application.

Gregor

Reply via email to