Re: RFC: (NT-related) optimization

sword-EOsNSARiLbg@xxxxxxxxxxxxxxxx wrote:
> 
> I'm new to SQLite and evaluating it to use it in a program that will
> run on MS Windows 2000/XP, without compatibility to Win9X, and the
> following is my concern about optimization ideas.

> 
> 1. Locking
> 
> In os.c, I found the function isNT(void) and the note
> 
> ** Windows file locking notes:
> **
> ** We cannot use LockFileEx() or UnlockFileEx() because those functions
> ** are not available under Win95/98/ME.  So we use only LockFile() and
> ** UnlockFile().
> 
> Why SQLite locking functions can't use NT-specific locking API
> by checking platform by isNT()? Apparently in sqliteOsReadLock
> isNT() is called to get page size or something, but not more than
> that.
 >

The scheme you propose would be more complex because
we would not be able to link against LockFileEx() and
UnlockFileEx().  Instead we would have to check for the
OS at runtime, then dynamically extract the entry points
from the appropriate DLLs.  This is all doable, but it
requires a lot of extra code.  And I'm not sure what it
buys you.  SQLite already implements a reader/writer
locking mechanism using LockFile() and it seem unlikely
that LockFileEx() is going to be significantly faster
than LockFile().

> 
> 2. OS_WINNT
> 

Again, this just adds complexity without any real performance
benefit.

> 
> 4. Adding inline keyword
> 
> SQLite uses its own atoi() to speed it up and according to
> http://www.hwaci.com/sw/sqlite/speed.html
> calling strtod() was its bottleneck but I can't find it in 2.7.3,
> then it looks optimization is on its way.
> In addition to inlining by hand, how about inlining by compiler?
> While C++ has keyword "inline", in C, ANSI C99 supports it.
> Putting inline on short internal functions, such as
> sqlite_aggregate_count(sqlite_func *p) in vdbe.c
> may produce faster code in inline-supported compilers.
> 

GCC inlines small functions even without the "inline"
keyword. Adding addition "inline" declarations in the
code is unlikely to make any speed difference.  But you
are welcomed to run some benchmarks yourself to try to
prove me wrong.


> 5. Allocator
> 
> In SQLite, allocator wrappers are sqliteMalloc_/sqliteFree_/sqliteRealloc_
> and they use malloc()/free() internally, but how about making internal
> allocator calls configurable in header sqlite.h? I'd like to use allocators
> other than malloc(). Replacing them with macro and placing definitions
> in sqlite.h will be sufficient.
> 

I have received many reports that the memory allocator
that WinNT supplies by default is REALLY SLOW and that
subtituting an alternative memory allocator can make a
significant speed difference.  This is a reasonable
request.
-- 
D. Richard Hipp -- drh-X1OJI8nnyKUAvxtiuMwx3w@xxxxxxxxxxxxxxxx -- 704.948.4565


To unsubscribe from this group, send an email to:
sqlite-unsubscribe-VgYJa0VH1e9BDgjK7y7TUQ@xxxxxxxxxxxxxxxx

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/