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