-----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, somebody came up with a hackish solution that could
probably be written to be more clean.
Matthew Arrington gives the below code:
#define SQLITE_WORK_BUFF_SIZE (128*1024) // make power of 2
#define SQLITE_WORK_BUFF_MASK (SQLITE_WORK_BUFF_SIZE-1)
char sqlite_workBuff[SQLITE_WORK_BUFF_SIZE];
int sqlite_writeIdx=0;
void *SQLITE_ALLOC(int nBytes)
{
~ void *ret;
~ sqlite_writeIdx = (sqlite_writeIdx + nBytes) & SQLITE_WORK_BUFF_MASK;
~ ret = sqlite_workBuff + sqlite_writeIdx;
~ sqlite_writeIdx+=nBytes;
~ return ret;
}
this idea could take being expanded on; as is it does leave room for
many screw-ups and hardcore memory corruption, especially in threaded
environments.
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?
|
| Thank
|
| Steve
|
| D. Richard Hipp wrote:
|
|> 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 you to run out of
|>> memory if the table is too large.
|>>
|>
|> This is also true of version 3.0 and (the soon to be released) version
|> 3.1. I believe this constraint is documented somewhere, though I
|> cannot say where right off hand. Somebody please correct me (and
|> submit documentation patches) if I am wrong.
|>
|>
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB43M3hDd4aOud5P8RApMzAJ4+qkchPTbM4CF9DWrIblE4AJHLRACffZON
mc8txoELVoMtnqph6G2+jX4=
=KoXS
-----END PGP SIGNATURE-----
