logo       

RFC: (NT-related) optimization: msg#00136

db.sqlite.general

Subject: RFC: (NT-related) optimization

Hi everyone,

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. But the last two is
not relevant to OS.
I would like to know how the design decisions will be done to the
following points in SQLite before re-inventing wheels.

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.

2. OS_WINNT

Related to 1, How about defining another configurable macro,
OS_WINNT to tune SQLite to NT platform? It's better than
checking OS dynamically, to remove dead code from executable.
Win9X platforms will be practically obsolete in a few years, therefore
having OS_WINNT aside from generic OS_WIN will be not bad idea.

3. UTF-16

This is not necessarily optimization, but in the another thread of the
list UTF-8 is proposed, but how about UTF-16(little-endian UCS-2)?
It is the internal code of NT platforms and Windows has a set of APIs
to handle those wide characters. Surely database size will be larger if
UTF-16 is used, but interaction will be the most natural in Windows.
Without UTF-16 support, storing UTF-16 strings always involves
binary encoding.

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.

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.


--
Kevin L.




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/





<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise