Afaik most of the binary indexes (index, FTS) can be mergesorted
together rather cheaply and then stored on disk. Using these rather than
converting everything to text and then parse that again would make it
very fast. This is what HH does.
Even faster is caching the result of the merge on disk (which HH also
does, but only in case of "merged" chm files, which doesn't work with
FPC generated CHM files yet), these are then stored as CHW.
But to invalidate the cache, it should be stored which CHMs were used to
generate it. So that the cache can be invalided.
I'll look into the various fpdoc and chm stuff from tomorrow, when I get
home again
I agree with you that need to do a storing on disk or to produce CHW.
And I will do this later.
Creating a new chm package additions also requires a lot of time.
But now I have not any documentation on chm format, I have found only
dribs and drabs.
The situation is such that the documentation seems an existing, but it
is very difficult to use for many reasons.
Actual version of lHelp has to work rightly and then I can do next
version. First start 1.5-2 sec I think it is well for loading entire
packet of chms and indexes.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
