[pilot-db-list] large DB support

[Yedidyah Bar-D. <di...@ta...>]

> > 2. The "large DB support" didn't work very well for him, so for now
> > I disabled it (compiled with '--with-vldb=0'). IIRC, it also wasn't
> > that much faster - and it _is_ an issue for him, having a 1000+
> > records DB with around 20 fields (still to change, but num of records
> > will not get smaller - it's his todo list). How experimental is this?
> > Is it going to become stable soon? Should I help debug this? Can I?
> 
> You compiled it!  Congratulations!  As best as I can tell, there are
> very few people on this list who have done so.  Be warned that many of
> the code paths seem to be unused in recent years, and that by
> including (or omitting) configuration flags you might soon find
> yourself in uncharted waters.

(repeating myself:)
I did
./configure --enable-standard --enable-debug --enable-sony=no --enable-handera=no --enable-fiveways=no --enable-make_plugins
With and without --with-vldb=0. Well, not the CVS one - only 1.1.0.
CVS I compiled only without it (that is, _with_ vldb support).
It wasn't that hard. Where is the catch?

> 
> Yes, it is probably going to become stable in the next release by
> simple method of removing all reference to the word "experimental".
> As far as I know (based on my recollection of submitted bug reports)
> it does not seem to add additional bugs.  I don't know about it's
> performance, but I think it purpose was simply to allow very large
> databases, not to necessarily make them work faster. (?)

Well, the 'configure --help' says:
"optimize for very large databases, and set the size of such a database".
Can you tell me what you think is the maximum of pilot-db without
this support, if it's not only optimization? It does work on a 1000+
record DB.

I did not yet try to reproduce the bug on the cvs - on 1.1.0 it sometimes
did not refresh the screen on Up/Down arrows. Since The User (my brother-
in-law) uses it daily, and is not friendly with computers, I chose for
him the slower but safer version. But it _is_ an issue.

> 
> Yes, you should help debug this! :) Submitting the slowness as a bug
> report to the SourceForge website, and then giving a sample database
> with some sample times would be good too.  I haven't yet tried much

I'll try to prepare something.
Maybe there is simply nothing to do? It is indeed a slow machine, and
a complex program. Are there profiling tools for this? prc does not
have gprof.

> profiling under POSE, but it does appear to be possible.  I'd guess
> (without having looked closely at the code) that there is lots of room
> for simple optimization.  If you can do it, wonderful, otherwise (like
> everything else) I'll try to get to it once we have a stable release.

OK.
-- 
Didi