|
RFC: (NT-related) optimization: msg#00136db.sqlite.general
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> |
|---|---|---|
| Previous by Date: | Wasted Space Within Files: 00136, Brady Hutmacher (AKA Capt. Hack'em) |
|---|---|
| Next by Date: | SQLite with Borland C++ Builder 6.0?: 00136, Luc Saint-Elie |
| Previous by Thread: | Wasted Space Within Filesi: 00136, Brady Hutmacher (AKA Capt. Hack'em) |
| Next by Thread: | Re: RFC: (NT-related) optimization: 00136, D. Richard Hipp |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |