Le mardi 11 janvier 2005 à 08:13 -0500, Steve Frierdich a écrit :
> Thanks Richard. We are using Sqlite on some military projects, and its
> on the WinCE I am most concern on using Sqlite.
I would similarly be concerned about using WinCE in military
projects :-)
ooops
D.Morel
signature.asc
Thanks Richard. We are using Sqlite on some military projects, and its
on the WinCE I am most concern on using Sqlite.
Steve
D. Richard Hipp wrote:
Steve Frierdich wrote:
I have been noticing all the email messages about excessive malloc
calls. Is there a serious bug in Sqlite about malloc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
~From what I can tell people are just in shock and awe that checking 3000
tables each holding several years of data for a company (again: several
years of data for 3000 different companies) calls malloc() several
million times.
Interesting enough,
Steve Frierdich wrote:
I have been noticing all the email messages about excessive malloc
calls. Is there a serious bug in Sqlite about malloc being called
excessively causing memory leaks in sqlite version 3? And if there is,
is there a way to fix it the source code?
There are no memory leaks
> SELECT x, y, z FROM table1 ORDER BY 2;
> SELECT x, y, z FROM table1 ORDER BY y;
> ...
> This is a standard SQL thing, apparently. It surprised me too
> when I first found out about it (and had to fix SQLite to do it.)
Using an integer is generally deprecated. It was left in the
std to
I have been noticing all the email messages about excessive malloc
calls. Is there a serious bug in Sqlite about malloc being called
excessively causing memory leaks in sqlite version 3? And if there is,
is there a way to fix it the source code?
Thank
Steve
D. Richard Hipp wrote:
Andrew
On Mon, 10 Jan 2005 17:07:11 -0500, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> This is a standard SQL thing, apparently. It surprised me too
> when I first found out about it (and had to fix SQLite to do it.)
Very interesting. Thanks.
Tom,
Yes I agree. It does make a lot of assumptions. I would not consider using
that code permanently without knowing exactly the way the system worked,
and then I'd add error checking code that would detect misuse and/or
overflow at run time. We use this type of allocation scheme for real time
Will Leshner wrote:
On Mon, 10 Jan 2005 13:49:21 -0800, [EMAIL PROTECTED]
By the way, "ORDER BY 1" I believe to mean order by column id = 1. So it's
not really a meaningless statement.
Is that true? I don't get the from the documentation, but I'm probably
just looking at it wrong.
Yes. You
Derrell Thanks for that!
I did not have the primary key set up right. (I'm an SQL newbie) which
forced me to use "order by."
By the way, "ORDER BY 1" I believe to mean order by column id = 1. So it's
not really a meaningless statement.
I think any "order by clause" is going to cause a per row
Andrew Shakinovsky wrote:
I have noticed with SQLite (at least this was true with 2.8x, not sure about
3x) that if you try to use an ORDER BY with a table that doesn't have an
index on the field you are ORDERing by, it will do the entire sort
(presumably just the keys) in memory. This will cause
[EMAIL PROTECTED] wrote:
>
> The "order by" clause I think is what causes the memory allocation of
> "aType" for each row.
I think you are right. The aType is cached when data is coming out
of the database file so the allocation only occurs once. But when
data is coming out of the sorter, the
On Mon, 10 Jan 2005 13:49:21 -0800, [EMAIL PROTECTED]
> By the way, "ORDER BY 1" I believe to mean order by column id = 1. So it's
> not really a meaningless statement.
Is that true? I don't get the from the documentation, but I'm probably
just looking at it wrong.
if the table is too large.
>>-Original Message-
>>From: Will Leshner [mailto:[EMAIL PROTECTED]
>>Sent: Monday, January 10, 2005 4:49 PM
>>To: sqlite-users@sqlite.org
>>Subject: Re: [sqlite] excessive malloc() calls
>>
>>
>>On Mon,
On Mon, 10 Jan 2005 13:43:20 -0800, [EMAIL PROTECTED]
> This does point out however, that Win32 users who need to use ORDER BY on a
> large table are paying a hefty price.
Is that true even if they are using ORDER BY properly?
I'm just doing the select statement I mentioned in my first message.
SELECT * FROM 'SPY' ORDER BY 1 ASC;
"1" is the column id which in my case I thought was a primary integer key.
The "order by" clause I think is what causes the memory allocation of
"aType" for each row.
I did not create the
I am sorry, typing too fast I had made typos which made my message not
understandable. So here it is again:
I would say it is one of the most dangerous code snippets I have seen
in a while.
The code makes a lot of assumptions but they are NOT explicitly stated.
It may work under some strictly
[EMAIL PROTECTED] writes:
> I switched my application over to SQLite3 and did some performance
> profiling and found that the majority of the processing time spent is
> making calls to malloc().
>
> sqlite3_step() is the function that is making all the excessive calls, one
> call per row fetched.
[EMAIL PROTECTED] wrote:
I switched my application over to SQLite3 and did some performance
profiling and found that the majority of the processing time spent is
making calls to malloc().
It sounds like you have a bad malloc() implementation. What
OS and compiler are you using. Malloc() on linux
>It would seem really useful to be able to compare the performance of
>two or more companies. Having each of them in a separate table means to
>do any kind of comparison you need a join. It would seem lots better
>to have a single table with a column for the company name. Eliminates
>LOTS of work
Subject: Re: [sqlite] excessive malloc() calls
On Mon, Jan 10, 2005 at 09:51:50AM -0800,
[EMAIL PROTECTED] wrote:
> sqlite3_step() is the function that is making all the excessive calls, one
> call per row fetched.
> about 3000 of these tables. One complete scan of all 3000 companies wi
On Mon, Jan 10, 2005 at 09:51:50AM -0800, [EMAIL PROTECTED] wrote:
> sqlite3_step() is the function that is making all the excessive calls, one
> call per row fetched.
> about 3000 of these tables. One complete scan of all 3000 companies will
> make roughly 5.5 million malloc() calls!
That
I switched my application over to SQLite3 and did some performance
profiling and found that the majority of the processing time spent is
making calls to malloc().
sqlite3_step() is the function that is making all the excessive calls, one
call per row fetched.
The program is a stock scanning /
23 matches
Mail list logo
