[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Memory allocation during commits
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Memory allocation during commits |
Date: |
Tue, 7 Jun 2005 01:24:55 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, Jun 06, 2005 at 08:31:48PM -0600, Derek Scherger wrote:
> Eric Anderson wrote:
> > Then another big chunk at database.cc:654 where we convert the c* to a
> > string, and then prune off the back if it is large. Sadly, we then do
> > exactly the same vprintf again in the sqlite3_exec_vprintf, and then
> > sqllite3 does 4 allocations of similar size during the parsing and
> > execution.
>
> the sqlite3 branch, if it hasn't been merged, removes the exec_vprintf
> stuff entirely and uses prepared statements instead. it might be
> interesting to see how much memory similar operations work using that
> branch. I don't think there's anything serious blocking that from being
> merged in but I'm not sure.
It hasn't been merged. The discussion is at:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/3258
AFAICT there are a few tweaks to make (formatting of error messages, a
stray comment, it'd be nice to clean up the dump_table stuff to not
use the printf stuff), but nothing blocking merging in to mainline.
I don't know enough about the guts of sqlite to know if this reduces
copies, but it certainly seems likely it would, and is _much_ more
appealing than forking sqlite...
-- Nathaniel
--
Sentience can be such a burden.