K 70574 [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 3. Juli 2007 12:12
An: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Betreff: Re: [sqlite] Re: In Mem Query Performance
Hi Ken,
Thanks a lot.
But this would require the key to be short. Will Check if this is acceptable
to all as we may not be able
ht-
Von: RaghavendraK 70574 [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 3. Juli 2007 18:21
An: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: Re: [sqlite] Re: In Mem Query Performance
Hi,
As said, i used a seperate ID (hash) but it made the performance very bad.
Hi,
As said, i used a seperate ID (hash) but it made the performance very bad.
Now it takes minutes.[Version: 3.4.0]
regards
ragha
unsigned long idGen(const string & id)
{
const char* __s = id.c_str();
unsigned long __h = 0;
for ( ; *__s; ++__s)
{
__
rg; [EMAIL PROTECTED]
Betreff: Re: [sqlite] Re: In Mem Query Performance
Just a thought regarding this key issue.
enhancement for sqlite, enable a "reverse Key" indexing method. Would this be
a simple change?
Ken
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hi
Just a thought regarding this key issue.
enhancement for sqlite, enable a "reverse Key" indexing method. Would this be
a simple change?
Ken
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hi
>Hi Ken,
>
>Thanks a lot.
>But this would require the key to be short. Will Check if this is
acce
diately and delete it!
*
- Original Message -
From: Ken
Date: Tuesday, July 3, 2007 0:46 am
Subject: Re: [sqlite] Re: In Mem Query Performance
> Timings:
>
> Calling Test Now
> TIME_ms=1210
> start=1183394494
> end=1183394496
>
> Calling Test Now
> TIME_ms=1164
> start=1183
--Ursprüngliche Nachricht-
Von: RaghavendraK 70574 [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 3. Juli 2007 12:12
An: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Betreff: Re: [sqlite] Re: In Mem Query Performance
Hi Ken,
Thanks a lot.
But this would require the key to be short. Will Check if thi
Hi
>Hi Ken,
>
>Thanks a lot.
>But this would require the key to be short. Will Check if this is
acceptable
>to all as we may not be able to port old db data if the key format is
changed.
>
Perhaps the key can be modified only for comparation. You store the
key as you want, but before compare
<[EMAIL PROTECTED]>
Date: Tuesday, July 3, 2007 0:46 am
Subject: Re: [sqlite] Re: In Mem Query Performance
> Timings:
>
> Calling Test Now
> TIME_ms=1210
> start=1183394494
> end=1183394496
>
> Calling Test Now
> TIME_ms=1164
> start=1183394504
> end=118
Timings:
Calling Test Now
TIME_ms=1210
start=1183394494
end=1183394496
Calling Test Now
TIME_ms=1164
start=1183394504
end=1183394505
(time in Ms is 1.2 and 1.1 ... )
Data generated using:
#include
#include
#include
#include
using namespace std;
int main()
{
fstr
At 12:16 02/07/2007, you wrote:
Hi,
Pls notify me if it can be brought down to 1 sec.
There is no mem constraint.
I don't know x86 asm or gcc for x86, but in powerpc asm, if i use
altivec libraries (libfreevec, f.e.) for string comparations, mem
moves/copies, sorts etc... i get from x2 to x1
; the intended recipient(s) is prohibited. If you receive this e-
> mail in error, please notify the sender by phone or email
> immediately and delete it!
>
> *********************
> - Original Message -
> From: Joe Wilson <[EMAIL PROTECTED]>
> Date: Sunday, July 1, 2007 12:47 pm
> Subject: Re: [
ect: Re: [sqlite] Re: In Mem Query Performance
> In addition,
>
> - make a new index only on column1
> - move the prepare before the loop to avoid reparsing the SELECT
> each time
> - use sqlite3_bind_* and sqlite3_reset in the loop.
> - move finalize after the loop.
> -
));
ret = sqlite3_prepare(db, buf, -1, &pVM, &szTail);
ret = sqlite3_step(pVM);
//lst.push_back();
ret = sqlite3_finalize(pVM);
}
//
time_t end = time(0);
cout<<"start="<
Date: Saturday, June 30, 2007 9:48 pm
Subject: [sqlite] Re: In Mem
In addition,
- make a new index only on column1
- move the prepare before the loop to avoid reparsing the SELECT each time
- use sqlite3_bind_* and sqlite3_reset in the loop.
- move finalize after the loop.
- query the test table directly - not the temporary ttest table.
- don't SELECT * if you on
Your keys are too large and have the same leading characters.
Since the first hundred characters are the same you waste a lot
of CPU time in comparisons.
Try to get your total key size down to a fraction of that size.
At least change your program to generate keys of this form
instead and it wi
h_back();
ret = sqlite3_finalize(pVM);
}
//
time_t end = time(0);
cout<<"start="<
Date: Saturday, June 30, 2007 9:48 pm
Subject: [sqlite] Re: In Mem Query Performance
> Hi RaghavendraK,
>
> * RaghavendraK 70574 <[EMAIL PROTECTED]> [2007-06-25 0
Hi RaghavendraK,
* RaghavendraK 70574 <[EMAIL PROTECTED]> [2007-06-25 08:45]:
> When the DB is opened in "in Memory mode",performance of query
> does not improve. For table which has 10 columns of type Text
> and each column having 128bytes data and having a total of
> 1 records.
that is smal
18 matches
Mail list logo
