Re: [sqlite] Compile 64bit version of SQLIte on Solaris?

[Lynton Grice]

I just tried to see what ELF class is in after running the following (added
-D_FILE_OFFSET_BITS=64):

/usr/local/bin/gcc -D_FILE_OFFSET_BITS=64 -c -fPIC -DHAVE_USLEEP  sqlite3.c

# file libsqlite3.so grep ELF
libsqlite3.so:  ELF 32-bit LSB dynamic lib 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available

How can I get the ELF class to reflect "ELF 64-bit"?

Any ideas?

Lynton

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Lynton Grice
Sent: 22 November 2010 09:33 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Compile 64bit version of SQLIte on Solaris?

Hi there,

The reason I ask is that I have created a C shared lib using SQLite
functions etc and the custom shared lib I have created needs to be ELF class
64.

At the moment I am getting the ELF class issues:
wrong ELF class: ELFCLASS32

That is why I am hoping I can compile the main SQLite shared lib in ELF
class 64..

This possible?

Thanks

Lynton


-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Lynton Grice
Sent: 22 November 2010 09:28 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Compile 64bit version of SQLIte on Solaris?

Hi there,

 

I am getting the following error when trying to compile SQLite on a Solaris
64 bit machine:

 

/usr/local/bin/gcc -m64 -R/usr/sfw/lib/64 -c -fPIC -DHAVE_USLEEP  sqlite3.c

sqlite3.c:1: sorry, unimplemented: 64-bit mode not compiled in

 

Can someone please let me know how I can do this so I can use SQLite on a 64
bit Solaris machine?

 

Thanks

 

Lynton

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Compile 64bit version of SQLIte on Solaris?

[Lynton Grice]

Hi there,

The reason I ask is that I have created a C shared lib using SQLite
functions etc and the custom shared lib I have created needs to be ELF class
64.

At the moment I am getting the ELF class issues:
wrong ELF class: ELFCLASS32

That is why I am hoping I can compile the main SQLite shared lib in ELF
class 64..

This possible?

Thanks

Lynton


-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Lynton Grice
Sent: 22 November 2010 09:28 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Compile 64bit version of SQLIte on Solaris?

Hi there,

 

I am getting the following error when trying to compile SQLite on a Solaris
64 bit machine:

 

/usr/local/bin/gcc -m64 -R/usr/sfw/lib/64 -c -fPIC -DHAVE_USLEEP  sqlite3.c

sqlite3.c:1: sorry, unimplemented: 64-bit mode not compiled in

 

Can someone please let me know how I can do this so I can use SQLite on a 64
bit Solaris machine?

 

Thanks

 

Lynton

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Compile 64bit version of SQLIte on Solaris?

[Lynton Grice]

Hi there,

 

I am getting the following error when trying to compile SQLite on a Solaris
64 bit machine:

 

/usr/local/bin/gcc -m64 -R/usr/sfw/lib/64 -c -fPIC -DHAVE_USLEEP  sqlite3.c

sqlite3.c:1: sorry, unimplemented: 64-bit mode not compiled in

 

Can someone please let me know how I can do this so I can use SQLite on a 64
bit Solaris machine?

 

Thanks

 

Lynton

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Loading a FTS3 table into ram without reindexing

[boscowitch]

Am Montag, den 22.11.2010, 01:24 + schrieb Simon Slavin:
> On 22 Nov 2010, at 12:49am, boscowitch wrote:
> 
> > now i switched to an Fulltext search table FTS3 which improved speed
> > drastically but it now need over ~15s on my 3Ghrz to load all entrys
> > into the ram FTS3 table (with simple tokenizer).
> > (the current code is in this db.c file in the init_db function
> > http://github.com/boscowitch/wadoku-notify/blob/master/src/db.c ) 
> > 
> > now i wanted to ask if i precreate the indexed table into the db file
> > how i can load/copy this table into a :memory: db without regeneratig
> > the whole index.
> 
> This may seem silly, but are you absolutely sure you need to load the 
> database into memory ?  I've seen some apps which to go great lengths to do 
> this but hardly slow down at all just accessing the database from disk.  If 
> you take the memory you were storing the database in, and use if for disk 
> caching instead you can get pretty good speeds just using FTS3 as intended.
> 
> Simon.

In Linux i had almost no problem without cachign and FTS3, because the
kernel caches, only after using some big app it was slow at first so i
forced it into ram.

on windows without any caching it was unbearable slow it allways took
20s or so...

havn't tested it with FTS3 and without copying it into ram, but i will
test it in windows, which will be the most slowest(exepct maby on maemo
on my n900 mobile where it now runs reasonable thanks to FTS3 ~0,5s
before 30s for one search).

does FTS3 some caching of its index. ? or can i force it to ? i guess
the index wold be enough
because reading one small entry from it's id will probably be fast
enough.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Loading a FTS3 table into ram without reindexing

[Simon Slavin]

On 22 Nov 2010, at 12:49am, boscowitch wrote:

> now i switched to an Fulltext search table FTS3 which improved speed
> drastically but it now need over ~15s on my 3Ghrz to load all entrys
> into the ram FTS3 table (with simple tokenizer).
> (the current code is in this db.c file in the init_db function
> http://github.com/boscowitch/wadoku-notify/blob/master/src/db.c ) 
> 
> now i wanted to ask if i precreate the indexed table into the db file
> how i can load/copy this table into a :memory: db without regeneratig
> the whole index.

This may seem silly, but are you absolutely sure you need to load the database 
into memory ?  I've seen some apps which to go great lengths to do this but 
hardly slow down at all just accessing the database from disk.  If you take the 
memory you were storing the database in, and use if for disk caching instead 
you can get pretty good speeds just using FTS3 as intended.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Loading a FTS3 table into ram without reindexing

[boscowitch]

Hi,

atm i'm developing an open source instant dictionary lookup tool
wadoku-notify (wadoku.de japanese german dictionary)

for speed improvement i used fadvise function to let the kernel load the
db file into memory, but now i ported the app to windows and mac os x
and i let sqlite do the ram loading over a memory database and sql
attach command.

now i switched to an Fulltext search table FTS3 which improved speed
drastically but it now need over ~15s on my 3Ghrz to load all entrys
into the ram FTS3 table (with simple tokenizer).
(the current code is in this db.c file in the init_db function
http://github.com/boscowitch/wadoku-notify/blob/master/src/db.c ) 

now i wanted to ask if i precreate the indexed table into the db file
how i can load/copy this table into a :memory: db without regeneratig
the whole index.

or can i advise sqlite to load at least the whole pre generated index
into the ram to speed it up?



if you are interested you can see an eary testing version without any
indexing and ram tables in action here (now with FTS3 it instantly
updates even if selection occurs very fast)
http://www.youtube.com/watch?v=uhwp0XKX9U8 

last but not least THANK YOU VERY MUCH!
though sqlite and FTS3 i could make a very usefull app without
reinventing the world.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_get_table() vs sqlite3_step

[Tito Ciuro]

Hi Igor,

No, no... I really meant a roundtrips to disk. So, while sqlite3_get_table() 
seemed like a faster but memory hungry mechanism to retrieve the result set, 
sqlite3_step() seemed that it would take longer, especially in disk-based 
systems, but more memory-efficient.

Thanks for pointing to me that sqlite3_get_table() is not faster than 
sqlite3_step().

-- Tito

On 21 Nov 2010, at 14:14, Igor Tandetnik  wrote:

> Tito Ciuro  wrote:
>> Let me start by saying that I'm aware that sqlite3_get_table() should not be 
>> used (as per the documentation). I'm curious about
>> one thing though: if the computer/device has sufficient memory to hold the 
>> result set returned by sqlite3_get_table(), wouldn't
>> it be more optimized performance-wise than calling sqlite3_step N times to 
>> obtain the same result set?  
> 
> sqlite3_get_table is just a wrapper around sqlite3_prepare/sqlite3_step.
> 
>> Sounds like sqlite3_get_table() would take less time to access the storage 
>> subsystem as opposed to sqlite_step() with multiple
>> roundtrips
> 
> You say "roundtrip" as if it's a network request to some remote machine or 
> something. Here, a "roundtrip" is a function call within the same process. In 
> this sense, a call to malloc is a roundtrip to memory allocation subsystem - 
> you want to avoid those at all costs, right?
> -- 
> Igor Tandetnik
> 
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_get_table() vs sqlite3_step

[Tito Ciuro]

Thanks a lot Max!

-- Tito

On 21 Nov 2010, at 14:04, Max Vlasov  wrote:

> On Sun, Nov 21, 2010 at 6:31 PM, Tito Ciuro  wrote:
> 
>> Hello,
>> 
>> Sounds like sqlite3_get_table() would take less time to access the storage
>> subsystem as opposed to sqlite_step() with multiple roundtrips, at the
>> expense of using lots more RAM, of course. So assuming RAM wasn't an issue,
>> why not use sqlite3_get_table()? Why is its usage being discouraged?
>> 
>> 
>> Tito, looking at the sources... sqlite3_get_table seems to be sqlite3_exec
> call with a callback and sqlite3_exec is sqlite3_prepare/sqlite3_step
> wrapper. So, probably no special access or performance boost
> 
> Max Vlasov
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_get_table() vs sqlite3_step

[Igor Tandetnik]

Tito Ciuro  wrote:
> Let me start by saying that I'm aware that sqlite3_get_table() should not be 
> used (as per the documentation). I'm curious about
> one thing though: if the computer/device has sufficient memory to hold the 
> result set returned by sqlite3_get_table(), wouldn't
> it be more optimized performance-wise than calling sqlite3_step N times to 
> obtain the same result set?  

sqlite3_get_table is just a wrapper around sqlite3_prepare/sqlite3_step.

> Sounds like sqlite3_get_table() would take less time to access the storage 
> subsystem as opposed to sqlite_step() with multiple
> roundtrips

You say "roundtrip" as if it's a network request to some remote machine or 
something. Here, a "roundtrip" is a function call within the same process. In 
this sense, a call to malloc is a roundtrip to memory allocation subsystem - 
you want to avoid those at all costs, right?
-- 
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Error in the Doc

[Igor Tandetnik]

Vander Clock Stephane  wrote:
> just to say you that the doc probably want to say :
> 
> If the 3rd parameter to sqlite3_open_v2() is not one of the combinations
> shown above or *NOT* one of the combinations
> shown above combined with the SQLITE_OPEN_NOMUTEX,
> SQLITE_OPEN_FULLMUTEX, SQLITE_OPEN_SHAREDCACHE and/or
> SQLITE_OPEN_PRIVATECACHE flags, then the behavior is undefined.
> 
> it's forget the word "*NOT*" :)

The current sentence structure of "not A or B" clearly means "not (A or B)" - 
in other words, "neither A nor B". I don't see how anyone could reasonably 
interpret it to mean "(not A) or B".

In any case, if you really want to clarify it, make it say "not A and not B". 
The phrase "not A or not B" changes the meaning.
-- 
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_get_table() vs sqlite3_step

[Max Vlasov]

On Sun, Nov 21, 2010 at 6:31 PM, Tito Ciuro  wrote:

> Hello,
>
> Sounds like sqlite3_get_table() would take less time to access the storage
> subsystem as opposed to sqlite_step() with multiple roundtrips, at the
> expense of using lots more RAM, of course. So assuming RAM wasn't an issue,
> why not use sqlite3_get_table()? Why is its usage being discouraged?
>
>
> Tito, looking at the sources... sqlite3_get_table seems to be sqlite3_exec
call with a callback and sqlite3_exec is sqlite3_prepare/sqlite3_step
wrapper. So, probably no special access or performance boost

Max Vlasov
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] sqlite3_get_table() vs sqlite3_step

[Tito Ciuro]

Hello,

Let me start by saying that I'm aware that sqlite3_get_table() should not be 
used (as per the documentation). I'm curious about one thing though: if the 
computer/device has sufficient memory to hold the result set returned by 
sqlite3_get_table(), wouldn't it be more optimized performance-wise than 
calling sqlite3_step N times to obtain the same result set?

Sounds like sqlite3_get_table() would take less time to access the storage 
subsystem as opposed to sqlite_step() with multiple roundtrips, at the expense 
of using lots more RAM, of course. So assuming RAM wasn't an issue, why not use 
sqlite3_get_table()? Why is its usage being discouraged?

Thanks,

-- Tito
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Error in the Doc

[Vander Clock Stephane]

Hello,

just to say you that the doc probably want to say :

If the 3rd parameter to sqlite3_open_v2() is not one of the combinations 
shown above or *NOT* one of the combinations
shown above combined with the SQLITE_OPEN_NOMUTEX, 
SQLITE_OPEN_FULLMUTEX, SQLITE_OPEN_SHAREDCACHE and/or
SQLITE_OPEN_PRIVATECACHE flags, then the behavior is undefined.

it's forget the word "*NOT*" :)

http://www.sqlite.org/c3ref/open.html
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Simon Slavin]

On 21 Nov 2010, at 11:46am, Kees Nuyt wrote:

>  wrote:
> 
>> Hi Simon,
>> 
>> Yup, on Solaris I ran this and it was 1000 milliseconds for the following:
>> 
>> int theReturn = sqlite3_sleep(1);
>> 
>> Any way you know I can make it sleep on Solaris for 1 millisecond? Any other
>> C tricks you know of?
> 
> Standard C Library Functions   usleep(3C)
> 
> NAME
> usleep - suspend execution for interval in microseconds

Good note.  But the original question remains: why does the SQLite VM under 
Solaris not implement sqlite3_sleep() with a resolution of at least 
milliseconds ?  It's not like Solaris is hampered by requirements for a tiny 
library !

I found some code in 'os_unix.c' that says

static int unixSleep(sqlite3_vfs *NotUsed, int microseconds){
#if OS_VXWORKS
[...]
#elif defined(HAVE_USLEEP) && HAVE_USLEEP

which suggests that OS_VXWORKS and HAVE_USLEEP are consulted to work out what 
resolution is available.  But then we descend into compile-time parameters and 
I don't know anything about them.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Lynton Grice]

Thanks Kees, much appreciated ;-)

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Kees Nuyt
Sent: 21 November 2010 01:47 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] SQLite really SLOW on Solaris?

On Sun, 21 Nov 2010 13:08:31 +0200, "Lynton Grice"
 wrote:

>Hi Simon,
>
>Yup, on Solaris I ran this and it was 1000 milliseconds for the following:
>
>int theReturn = sqlite3_sleep(1);
>
>Any way you know I can make it sleep on Solaris for 1 millisecond? Any
other
>C tricks you know of?
>

Standard C Library Functions   usleep(3C)

NAME
 usleep - suspend execution for interval in microseconds

SYNOPSIS
 #include 

 int usleep(useconds_t useconds);

DESCRIPTION
 The usleep() function suspends the caller from execution for
 the  number  of microseconds specified by the useconds argu-
 ment.  The  actual  suspension  time  might  be  less   than
 requested  because any caught signal will terminate usleep()
 following execution of that signal's catching  routine.  The
 suspension  time  might be longer than requested by an arbi-
 trary amount because of the scheduling of other activity  in
 the system.

 If the value of useconds is 0, then the call has no effect.

 The use of the usleep() function has no effect on the action
 or  blockage of any signal. In a multithreaded process, only
 the invoking thread is suspended from execution.

RETURN VALUES
 On completion,  usleep()  returns  0.  There  are  no  error
 returns.

ERRORS
 No errors are returned.

USAGE
 The usleep() function is included for its historical  usage.
 The nanosleep(3C) function is preferred over this function.

-- 
  (  Kees Nuyt
  )
c[_]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Kees Nuyt]

On Sun, 21 Nov 2010 13:08:31 +0200, "Lynton Grice"
 wrote:

>Hi Simon,
>
>Yup, on Solaris I ran this and it was 1000 milliseconds for the following:
>
>int theReturn = sqlite3_sleep(1);
>
>Any way you know I can make it sleep on Solaris for 1 millisecond? Any other
>C tricks you know of?
>

Standard C Library Functions   usleep(3C)

NAME
 usleep - suspend execution for interval in microseconds

SYNOPSIS
 #include 

 int usleep(useconds_t useconds);

DESCRIPTION
 The usleep() function suspends the caller from execution for
 the  number  of microseconds specified by the useconds argu-
 ment.  The  actual  suspension  time  might  be  less   than
 requested  because any caught signal will terminate usleep()
 following execution of that signal's catching  routine.  The
 suspension  time  might be longer than requested by an arbi-
 trary amount because of the scheduling of other activity  in
 the system.

 If the value of useconds is 0, then the call has no effect.

 The use of the usleep() function has no effect on the action
 or  blockage of any signal. In a multithreaded process, only
 the invoking thread is suspended from execution.

RETURN VALUES
 On completion,  usleep()  returns  0.  There  are  no  error
 returns.

ERRORS
 No errors are returned.

USAGE
 The usleep() function is included for its historical  usage.
 The nanosleep(3C) function is preferred over this function.

-- 
  (  Kees Nuyt
  )
c[_]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Lynton Grice]

Hi Simon,

Yup, on Solaris I ran this and it was 1000 milliseconds for the following:

int theReturn = sqlite3_sleep(1);

Any way you know I can make it sleep on Solaris for 1 millisecond? Any other
C tricks you know of?

Thanks ;-)

Lynton

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin
Sent: 21 November 2010 12:23 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLite really SLOW on Solaris?


On 21 Nov 2010, at 10:10am, Lynton Grice wrote:

> in my "queue implementation" I add in a:
> 
> sqlite3_sleep(1);
> 
> Essentially I wanted to sleep for "1 millisecond" between sends to the
queue
> (in the send function itself), so that if the sender is sending too fast
it
> allows receivers to get messages 
> 
> On Debian it sleeps for 1 millisecond, BUT on the Solaris VM it sleeps for
1
> second!!! Not one millisecond..why???

See



Apparently the Solaris implementation of xSleep() is weird.  Just out of
interest, do

int theReturn = sqlite3_sleep(1);

(or some equivalent) on both platforms and look at the values you get
returned.  Do you get 1 on one platform and 1000 on the other ?

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Simon Slavin]

On 21 Nov 2010, at 10:10am, Lynton Grice wrote:

> in my "queue implementation" I add in a:
> 
> sqlite3_sleep(1);
> 
> Essentially I wanted to sleep for "1 millisecond" between sends to the queue
> (in the send function itself), so that if the sender is sending too fast it
> allows receivers to get messages 
> 
> On Debian it sleeps for 1 millisecond, BUT on the Solaris VM it sleeps for 1
> second!!! Not one millisecond..why???

See



Apparently the Solaris implementation of xSleep() is weird.  Just out of 
interest, do

int theReturn = sqlite3_sleep(1);

(or some equivalent) on both platforms and look at the values you get returned. 
 Do you get 1 on one platform and 1000 on the other ?

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite really SLOW on Solaris?

[Lynton Grice]

Hi Eric, Hi Roger,

Interesting, I found the issue with the "slow solaris issue".

You see in my "queue implementation" I add in a:

sqlite3_sleep(1);

Essentially I wanted to sleep for "1 millisecond" between sends to the queue
(in the send function itself), so that if the sender is sending too fast it
allows receivers to get messages 

On Debian it sleeps for 1 millisecond, BUT on the Solaris VM it sleeps for 1
second!!! Not one millisecond..why???

Why would that be? Could it be that the OS clocks are out? The moment I took
this out of the code on Solaris it was super fast just like it was on
Debian.

Any ideas?

Lynton

-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Eric Smith
Sent: 20 November 2010 09:13 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] SQLite really SLOW on Solaris?

Lynton Grice wrote:

> Many thanks for your feedback, much appreciated ;-)
> 
> But why would that happen on Solaris and not Debian?

Did you try it on real OSs & not VMs?  Are you sure the host OS is
giving the same compute & disk slices to the VMs?  Any other differences
in those mappings?

Are the VMs running on the same host box?  If not, are they running on
the same hardware and host OS?

Along the lines of Roger's comment, some VM implementations have 
OS clocks that simply don't work right -- they run too fast or too slow 
(I have personally observed differences of up to 3x), because they 
assume they are on real hardware.  Have you tested that?

Did you try compiling it with profiling data turned on to see where the
bottlenecks are (using gcc's -pg flag plus gprof(1))?

Or, as a simpler test, you could run your app from strace(1) (assuming
solaris has such a thing) to see if you are spending loads of time in
system calls as Roger hypothesized.

> Also, how would I pass the -D flags? Do I do that when I compile SQLite?

Yes -- those are arguments to GCC that are similar to writing a #define 
compiler directive into your code.  So saying

gcc -DFOO=bar ... 

would be like writing

#define FOO bar

into the code.

The sqlite.org docs describe what they do pretty well iirc.

Eric

--
Eric A. Smith

You can observe a lot by watching.
-- Yogi Berra
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users