From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Clemens Ladisch [clem...@ladisch.de] Sent: Wednesday, September 11, 2013 18:57 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Query preperation time does not scale linearly with growth of no. of tables
>Harmen de Jong - CoachR Group B.V. wrote: >> http://www.coachrdevelopment.com/share/callstack_tree.html >> >> This shows most time is spend on sqlite3CodeRowTriggerDirect. > >I'd guess the actual culprit is the loop in getRowTrigger (which does >not show up because it is inlined): > > /* It may be that this trigger has already been coded (or is in the > ** process of being coded). If this is the case, then an entry with > ** a matching TriggerPrg.pTrigger field will be present somewhere > ** in the Parse.pTriggerPrg list. Search for such an entry. */ > for(pPrg=pRoot->pTriggerPrg; > pPrg && (pPrg->pTrigger!=pTrigger || pPrg->orconf!=orconf); > pPrg=pPrg->pNext > ); We have put a timer around this 'inline' function and indeed as you suggest this is causing a huge part of the 'overhead'. This specific code takes 45.28% of the total time. What it does is keeping a list (Parse::pTriggerPrg) of trigger programs that are already created and every time a trigger program is created, it checks this list to see if it is already created. Obviously this list becomes longer as the foreign keys are looped through. Hereby our earlier assumption that the increasement was polynomial because of two nested loops seems to be wrong. So after improving this feature we still have to find about another 25% -;). _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
