On 12 sep. 2013, at 07:20, "James K. Lowden" <jklow...@schemamania.org<mailto:jklow...@schemamania.org>> wrote:
On Tue, 10 Sep 2013 12:58:21 +0000 Harmen de Jong - CoachR Group B.V. <har...@coachr.com<mailto:har...@coachr.com>> wrote: I think the way I wrote our timings were not that clear, since they are definately exponentially. The numbers from my previous post refer to the multiplier between the test cases. Just to make it clear, here follows the same tests, but then expressed in msec of total time per test. 500 tables - 10 msec in total 1000 tables - 25 msec in total 5000 tables - 298 msec in total 10000 tables - 985 msec in total I don't know what you mean by "exponentially". 500 .020 ms/table 1000 .025 ms/table 5000 .0596 ms/table 10000 .0985 ms/table Linearly, I'd say. It may help to look at it graphically. Well, actually it is neither of both (calling it exponentially was a mistake on my side). The increase in time is polynomial where we would expect an increase that is more or less linearly. http://www.schemamania.org/sqlite/graph.pdf we cannot find anything in there that would explain an exponential groth in time. I doubt you will. Well, the non-linear increase in time (polynomial increase) is there, so sooner or later we will find an explanation. In the mean time we already traced it down further by doing some profiling. You will find the result of this profiling (where time per function is expressed in percentage of the total time taken) here: http://www.coachrdevelopment.com/share/callstack_tree.html This shows most time is spend on sqlite3CodeRowTriggerDirect (the second one where it loops though FK's that point to B). However, now the question why this piece of code seems to be causing a polynomial increase still remains. Next question is if it can be improved for use cases with a large number of tables. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
