Comments on: SQLite simple timing profiler patch http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/ Chaotic solutions and random thoughts from the restless mind of a notorious problem solver (TM), by Andre Beckedorf Tue, 24 Apr 2012 02:48:27 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: SQLite performance tuning and optimization on embedded systems | http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-27854 SQLite performance tuning and optimization on embedded systems | Sun, 21 Aug 2011 04:07:40 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-27854 [...] Order the tables correctly in SELECTs. Put a table left-most if it is lacking an index on the relation. More details are here. In general: Check the order of tables in the SELECT statement. A different permutation may be more optimal. Profile. [...] [...] Order the tables correctly in SELECTs. Put a table left-most if it is lacking an index on the relation. More details are here. In general: Check the order of tables in the SELECT statement. A different permutation may be more optimal. Profile. [...]

]]> By: SQLite and pysqlite « Abner’s Postgraduate Days http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-23123 SQLite and pysqlite « Abner’s Postgraduate Days Wed, 03 Feb 2010 21:05:32 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-23123 [...] SQLite simple timing profiler patch [...] [...] SQLite simple timing profiler patch [...]

]]> By: Python and Sqlite « Abner’s Postgraduate Days http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-23122 Python and Sqlite « Abner’s Postgraduate Days Wed, 03 Feb 2010 21:00:24 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-23122 [...] SQLite simple timing profiler patch [...] [...] SQLite simple timing profiler patch [...]

]]> By: Daniel http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-22789 Daniel Thu, 12 Feb 2009 15:56:40 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-22789 I don' understand what to do with any of the two files? Coud you do please an step by step guide. Thank you. I don’ understand what to do with any of the two files?
Coud you do please an step by step guide.
Thank you.

]]> By: Mahalakshmi http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-7646 Mahalakshmi Mon, 16 Apr 2007 08:36:07 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-7646 Hi, I created a table named MUSIC in sqlite.It consists of 11 fields which is as follows. "create table MUSIC(Id integer primary key, Album text not null collate nocase default 'Unknown' , URL text not null collate nocase default 'Unknown' , Duration integer, Track integer, BitRate integer, sampleRate integer, Channels integer, Genre text not null collate nocase default 'Unknown', Artist text not null collate nocase default 'Unknown', Filesize integer);" I want to optimise the speed so i performed indexing for Album,Artist and Genre fields alone. But i could not find anyoptimization after indexing these 3 fields. I tried with indexing all the fields but still i could not achieve optimization. I will often use only these following statements "select distinct Album from MUSIC;" "select distinct Artist from MUSIC;" " select distinct Album from MUSIC where Artist=''A.R.Rehman' ;" " select URL from MUSIC where Artist=''A.R.Rehman' and Album='Vantae Mathram';" " select * from MUSIC where Artist=''A.R.Rehman' and Album='Vantae Mathram';" Can u please help me to make maximum optimization for the previous statements. Regards, M.Mahalakshmi Hi,

I created a table named MUSIC in sqlite.It consists of 11 fields which is as follows.

“create table MUSIC(Id integer primary key,
Album text not null collate nocase default ‘Unknown’ ,
URL text not null collate nocase default ‘Unknown’ ,
Duration integer,
Track integer,
BitRate integer,
sampleRate integer,
Channels integer,
Genre text not null collate nocase default ‘Unknown’,
Artist text not null collate nocase default ‘Unknown’,
Filesize integer);”

I want to optimise the speed so i performed indexing for Album,Artist and Genre fields alone.
But i could not find anyoptimization after indexing these 3 fields.
I tried with indexing all the fields but still i could not achieve optimization.

I will often use only these following statements

“select distinct Album from MUSIC;”
“select distinct Artist from MUSIC;”
” select distinct Album from MUSIC where Artist=”A.R.Rehman’ ;”
” select URL from MUSIC where Artist=”A.R.Rehman’ and Album=’Vantae Mathram’;”
” select * from MUSIC where Artist=”A.R.Rehman’ and Album=’Vantae Mathram’;”

Can u please help me to make maximum optimization for the previous statements.

Regards,
M.Mahalakshmi

]]> By: “Yet Another Zaurus Media Player”… done differently . (Phase 2: Development progress, no release yet.) at Katastrophos.net Blog http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-2570 “Yet Another Zaurus Media Player”… done differently . (Phase 2: Development progress, no release yet.) at Katastrophos.net Blog Sat, 06 Jan 2007 03:49:16 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-2570 [...] With that being said, different rules in database design apply for embedded systems: In the third approach I already created a pretty decent database schema. Something I naturally would have done on a desktop system. Keeping the layout clean, using relations where applicable, minimizing data storage requirements. On a desktop system dereferencing and joining tables is fast. However, not so on my Zaurus: Simple left-joins over three tables would take up to a few hundred milliseconds. In contrast, these queries are almost unmeasurable on my desktop system, meaning they were faster than 10 ms. Now add a few other equally expensive queries to that and imagine, you’re doing a search on your playlist with 2000 items. Do you want to wait 3 seconds or longer for the result? That’s not what I call interactive. So, I had a nice profiling, optimizing and testing marathon last weekend. To make a long story short, after analyzing the bottlenecks and also having a lengthy discussion with a DB-guru friend, I ended up simplifying the database schema in a direction I wouldn’t normally take on a desktop system. It’s not totally ugly now, but it’s just not as relational as you might expect a SQL database to be. Also, some data is redundantly held in temporary tables, which isn’t nice either, but helps performance A LOT. In order to do the profiling I made some changes to the SQLite codebase, which I will post shortly along with some optimization hints. Update: Hints here, patch here. [...] [...] With that being said, different rules in database design apply for embedded systems: In the third approach I already created a pretty decent database schema. Something I naturally would have done on a desktop system. Keeping the layout clean, using relations where applicable, minimizing data storage requirements. On a desktop system dereferencing and joining tables is fast. However, not so on my Zaurus: Simple left-joins over three tables would take up to a few hundred milliseconds. In contrast, these queries are almost unmeasurable on my desktop system, meaning they were faster than 10 ms. Now add a few other equally expensive queries to that and imagine, you’re doing a search on your playlist with 2000 items. Do you want to wait 3 seconds or longer for the result? That’s not what I call interactive. So, I had a nice profiling, optimizing and testing marathon last weekend. To make a long story short, after analyzing the bottlenecks and also having a lengthy discussion with a DB-guru friend, I ended up simplifying the database schema in a direction I wouldn’t normally take on a desktop system. It’s not totally ugly now, but it’s just not as relational as you might expect a SQL database to be. Also, some data is redundantly held in temporary tables, which isn’t nice either, but helps performance A LOT. In order to do the profiling I made some changes to the SQLite codebase, which I will post shortly along with some optimization hints. Update: Hints here, patch here. [...]

]]> By: SQLite performance tuning and optimization on embedded systems at Katastrophos.net Blog http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-2471 SQLite performance tuning and optimization on embedded systems at Katastrophos.net Blog Thu, 04 Jan 2007 10:31:25 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-2471 [...] Software « “Yet Another Zaurus Media Player”… done differently . (Phase 2: “Development progress, no release yet.”) SQLite simple timing profiler patch » [...] [...] Software « “Yet Another Zaurus Media Player”… done differently . (Phase 2: “Development progress, no release yet.”) SQLite simple timing profiler patch » [...]

]]> By: Andre http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/comment-page-1/#comment-2470 Andre Thu, 04 Jan 2007 10:29:48 +0000 http://katastrophos.net/andre/blog/2007/01/04/sqlite-simple-timing-profiler-patch/#comment-2470 Please note, that this patch only measures the raw CPU time elapsed while executing a query. This is not equal to the realtime requirements. Please note, that this patch only measures the raw CPU time elapsed while executing a query. This is not equal to the realtime requirements.

]]>