> Did you try www.aducom.com/sqlite, you can create it dynamically in your
> code or use it as VCL-component.
> It also works in Delphi6
>
> Use the Database component and the Query component, you get a
> tdataset-alike resultset.
That's the one we were using initially that seemed slow. I
Tried to compile your wrapper this morning with no luck
The code seems to be written with Delphi 7 or higher? We are still
using delphi 6 which doesn't have the SysUtils data structure
TFormatSettings, and the functions FormatDateTime have different
declarations (only 2 paramaters)
Those
out of curiocity, can you give a try to my delphi wrappers?
http://www.sqlite.org/contrib
(not Tdataset replacement, though, but they should be quite fast for this
reason. also try the "serverCursor" setting, which allows you to step thorugh
the result set one at a time, meaning there is no
No, the DLL wasn't the issue (heck the entire program is a DLL anyway
and that's worked well for ages)
We eventually discoverd through profiling the Delphi componants we
had started using were the slow point, tossed them, and tried someone
elses version (some stuff adapted by someone called
I wouldn't think DLL calling overhead would be significant
when dealing with things as slow (relatively) as a database.
Is it really necessary for it to be a DLL?
You might be able to statically link it and remove that overhead.
Are you using COM or ActiveX to call it? If I remember right
they
> H The fact that the freelist size is different
> suggests either a bug in sqlite3_analyzer or a corrupt
> database file. What does "PRAGMA integrity_check" say?
It returned a batch of Page not used (from about 4 to 48 I think).\
That was it
> What OS did you say you are using?
> > CREATE INDEX myMyIndex ON myTable (myKey);
> > CREATE UNIQUE INDEX [pkPrimary] ON [myTable] ([myKey], [NumOne]);
> > CREATE INDEX myNumOneIndex ON myTable (NumOne);
>
> Why did you chose these indexes?
> Updates and Inserts are faster with fewer indices.
> Perhaps they can be reduces?
>
>
> Out of curiousity, have you tried doing a plain INSERT instead of INSERT
> OR REPLACE INTO?
> Since you have no unique fields in your table, I'm not exactly sure how
> or why you might get an
> INSERT failure, but perhaps Sqlite is doing some sort of data comparison
> on each insert.
We have
> The myMyIndex will only slow you down. myNumOneIndex
> will help if you have queries that use the numOne column.
Hurm, yes that makes sense. it wasn't supposed to be there, but was
added just incase it helped, which it didn't
> What is the output from sqlite3_analyzer?
Unfortunatly didn't
Ok I hadn't toyed with those. Just tried it, the speed for queries
hasn't increased much, but a little
However, I started getting hard drive thrashes for 10+ seconds from
time to time. Will investigate the cahce further to see what suits
this app
> Did you try increasing the page cache size.
Did you try increasing the page cache size. Your data set is very big.
pragma page_cache = 2;
This should at least improve the speed for queries.
Clive
"Chris Schirlinger" <[EMAIL PROTECTED]> on 02-02-2005 09:07:49
Please respond to [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
> What speed were you expecting?
> Are you comparing it to another database? If so what are the results for that
> database?
Anything better than what we got. The results are the worst we have
gotton from any DB or any self rolled data system (Jet is better, het
shouldn't be better)
After more
What speed were you expecting?
Are you comparing it to another database? If so what are the results for that
database?
Clive
"Chris Schirlinger" <[EMAIL PROTECTED]> on 02-02-2005 06:00:45
Please respond to [EMAIL PROTECTED]
To: sqlite-users@sqlite.org
cc:(bcc: clive/Emultek)
I've got a 6 million row DB in SQLite 3, but getting... odd results
which don't match up with the speed tests I've seen
The statement:
SELECT * FROM myTable WHERE myKey=1000
takes between 1 second to 4 or 5 on spikes. The returned result set
is ~2000 records. I havn't seen more than 2000
14 matches
Mail list logo
