Hi John,
there isn't really much to remove, but nevertheless I
followed your advice and replaced the sqlite select
by a small standard tcl procedure. Maybe that set me
on the right track.
There were also some exceptionally high execution
times in between, but not in every test run and not
always
Ulrich, try designing an experiment which removes SQLITE and measures
the performance of the other software layers. That might resolve your
dilemma.
JS
Ulrich Schöbel wrote:
Hi Richard,
thanks for trying to reproduce my 'problem'.
I'm using Linux 2.6.12 (Ubuntu Breezy Badger, a debian distr
Ulrich Schöbel wrote:
> Hi Richard,
>
> thanks for trying to reproduce my 'problem'.
>
> I'm using Linux 2.6.12 (Ubuntu Breezy Badger, a debian distro),
> Tcl/Tk 8.4.12, sqlite 3.3.4, all pretty recent versions.
>
> I made the same tests today with the same results.
>
> Nevertheless, sqlite is by f
On February 22, 2006 05:59 am, Adrian Ho wrote:
> On Wed, Feb 22, 2006 at 11:11:45AM +0200, Ulrich Sch?bel wrote:
> > I tried your script and got, after a slight modification, quite
> > consistent results. When I tried it as is, I got slightly varying
> > time results with a peak in the 50 to 100 r
On 2/21/06, Jose Da Silva <[EMAIL PROTECTED]> wrote:
> On February 21, 2006 12:48 pm, Jay Sprenkle wrote:
> > Sqlite has been very fast for me. If you need raw blazing
>
> Well, sqlite is definitely fast in relation to other sqls, but every sql
> has overhead, and they all can't match direct access
Michael Knigge <[EMAIL PROTECTED]> wrote:
> > THe bigger question is why you are designing a new system to
> > work with SQLite-2. SQLite-2 is in maintenance for use on legacy
>
> Eh... sorry, I was in a hurry of course I use sqlite3_finalize()!
>
>
> > systems. Use SQLite-3 instead. sqli
THe bigger question is why you are designing a new system to
work with SQLite-2. SQLite-2 is in maintenance for use on legacy
Eh... sorry, I was in a hurry of course I use sqlite3_finalize()!
systems. Use SQLite-3 instead. sqlite3_finalize() cannot fail
for any reason other than SQLITE
On Wednesday 22 February 2006 15:59, Adrian Ho wrote:
> > Do you come to similar results?
>
> Nope, mine were a lot more consistent (Centrino 1.6GHz laptop, 512MB RAM):
>
> t(1)=254 microseconds per iteration
> t(5)=186.6 microseconds per iteration
> t(10)=156.1 microseconds per iteration
> t(50)=
On Wed, Feb 22, 2006 at 11:11:45AM +0200, Ulrich Sch?bel wrote:
> I tried your script and got, after a slight modification, quite
> consistent results. When I tried it as is, I got slightly varying
> time results with a peak in the 50 to 100 region. Then I
> commented out all lines concerning the d
Hi Richard,
thanks for trying to reproduce my 'problem'.
I'm using Linux 2.6.12 (Ubuntu Breezy Badger, a debian distro),
Tcl/Tk 8.4.12, sqlite 3.3.4, all pretty recent versions.
I made the same tests today with the same results.
Nevertheless, sqlite is by far faster than mySQL, so I'm going
to
Michael Knigge <[EMAIL PROTECTED]> wrote:
> All,
>
> I wonder what I have to do if sqlite_finalize() fails? sqlite_close()
> will fail if there are any prepared statements associated with a
> database handle - so I can't close.
>
> Due to the manual, sqlite_finalize() could return SQLITE_ABORT
Ulrich =?iso-8859-1?q?Sch=F6bel?= <[EMAIL PROTECTED]> wrote:
>
> % time {db eval {select * from cust_persons where first_name='Ulrich'}} 1000
> 75.498 microseconds per iteration
> % time {db eval {select * from cust_persons where first_name='Ulrich'}} 1
> 51.6179 microseconds per iteration
> %
Hi all,
out of curiosity I made the same timing tests as described
in my posting 'Strange execution times' with mySQL.
There's no reason to whine about the 300 microseconds
at 100 selects. MySQL, connected by mysqltcl to Tcl, delivers
after about 26305 microseconds, decreasing for 1
runs to a
Hi.
Can anyone tell me how to control the affinity mode?
Affinity mode is described on
http://www.sqlite.org/datatype3.html (section 6 "Other Affinity
Modes")
Jarl
All,
I wonder what I have to do if sqlite_finalize() fails? sqlite_close()
will fail if there are any prepared statements associated with a
database handle - so I can't close.
Due to the manual, sqlite_finalize() could return SQLITE_ABORT - do I
have to call sqlite_finalize() again in this c
Hi Ran,
no, sorry. It's running on a normal Linux PC, runnning 24/7.
No laptop, no stepping up. Time calculation is probably
a bit less accurate in the lower regions, but not that much.
It's really a mind boggler.
Thanks and kind regards
Ulrich
On Wednesday 22 February 2006 11:27, Ran wrote:
Could it be connected to the stepping up of the CPU? Do you run those tests
on a laptop? This at least could explain how the many iterations are faster
(the CPU has time to step up).
It does not explain why the 10 and 5 are fast as well (maybe when doing few
iterations, the time calculation is less
Hi Adrian,
I tried your script and got, after a slight modification, quite
consistent results. When I tried it as is, I got slightly varying
time results with a peak in the 50 to 100 region. Then I
commented out all lines concerning the deletion, creation
and filling to get the pure retrieval time
18 matches
Mail list logo
