Thanks for the answers. I did give compiling with 3.5.9 a try, but it looks
like the changes in vfs are too great:
sqlite3async.c: In function `asyncOpen':
sqlite3async.c:1019: warning: initialization from incompatible pointer type
sqlite3async.c: In function `asyncAccess':
sqlite3async.c:1182: error: too many arguments to function
sqlite3async.c: At top level:
sqlite3async.c:1290: warning: initialization from incompatible pointer type
sqlite3async.c:1291: warning: initialization from incompatible pointer type
sqlite3async.c:1292: warning: initialization from incompatible pointer type
sqlite3async.c:1293: warning: initialization from incompatible pointer type
sqlite3async.c:1294: warning: initialization from incompatible pointer type
sqlite3async.c:1295: warning: initialization from incompatible pointer type
sqlite3async.c:1296: warning: initialization from incompatible pointer type
sqlite3async.c:1297: warning: initialization from incompatible pointer type
sqlite3async.c:1299: warning: initialization from incompatible pointer type
I was able to build and use the asynch i/o module with 3.6.15 without too much
difficulty.
I need to re-verify this, but the 3.6.15 version seems to be faster than the
3.5.9 version.
Also, I get the best performance (without the asynch io module coded in) is
with these two pragmas together:
sqlite3_exec(db, "pragma synchronous=off;", 0, 0, &zErrMsg);
sqlite3_exec(db, "pragma locking_mode=exclusive;", 0, 0, &zErrMsg);
Since I only plan on using this db from a single process, and don't need to
handle the case of power failure or other hardware issues, this combo seems to
make the most sense. My only concern is to get data out of memory as quickly
as possible, and be able to restore it back to memory. The latter is a very
infrequent occurrence - less than 1% of the time.
Ray
-----Original Message-----
From: Dan [mailto:danielk1...@gmail.com]
Sent: Thursday, June 18, 2009 3:00 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Asynchronous I/O Module For SQLite
On Jun 18, 2009, at 11:45 PM, Rizzuto, Raymond wrote:
> Simon,
>
> I appreciate your input, but I don't think I have provided enough
> details on the constraints my application has to meet for you to
> evaluate whether asynch i/o is a good solution or not for me.
>
> I don't think it is practical for me to get into that level of
> detail, even if I wanted to. I really just want some clarification
> on how to use asynch i/o module, as described on
> http://sqlite.org/asyncvfs.html
> . My questions are very simple:
>
> 1) sqlite3async.c and sqlite3async.h aren't in the amalgamation's.
> I can get them from sqlite-3.6.15.tar.gz, but I wanted to verify
> that this was the correct procedure, and that those 2 files are all
> I need.
That's all you need.
> 2) Since these two files are compiled into the app, and seem to
> stand apart from the core sqlite3, I was curious if I could use them
> with sqlite3 version 3.5.9 since that version is already in use in
> my organization.
Might very well work on unix systems. I think there were some
incompatibilities
with the windows OS layer that were fixed more recently than 3.5.9
though.
Dan.
> If no one can answer those questions, I'll just have to give it a
> try, and see if that meets my needs or not. It may be that sqlite3,
> with or without the asynch i/o module, isn't the right choice for my
> needs.
>
> Ray
>
> -----Original Message-----
> From: Simon Slavin [mailto:slav...@hearsay.demon.co.uk]
> Sent: Thursday, June 18, 2009 12:10 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Asynchronous I/O Module For SQLite
>
>
> On 18 Jun 2009, at 2:15pm, Rizzuto, Raymond wrote:
>
>> I'm actually memory limited, which is why I am looking at moving
>> infrequently needed object to persistent store with sqlite3. I like
>> the idea of using the asynchronous i/o module so that the writing
>> can be done in a background thread, but still allow the main thread
>> to retrieve data that has been written or is in queue to be written.
>
> Aren't those two things in conflict ? Caching and multiple concurrent
> threads are two features which chew up a great deal of memory: a
> cache /is/ memory, and each independent thread requires its own
> working-memory. If you're trying to minimise memory-usage you tend to
> have no caching and single threads.
>
> Simon.
>
>
> IMPORTANT: The information contained in this email and/or its
> attachments is confidential. If you are not the intended recipient,
> please notify the sender immediately by reply and immediately delete
> this message and all its attachments. Any review, use, reproduction,
> disclosure or dissemination of this message or any attachment by an
> unintended recipient is strictly prohibited. Neither this message
> nor any attachment is intended as or should be construed as an
> offer, solicitation or recommendation to buy or sell any security or
> other financial instrument. Neither the sender, his or her employer
> nor any of their respective affiliates makes any warranties as to
> the completeness or accuracy of any of the information contained
> herein or that this message or any of its attachments is free of
> viruses.
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
