From: dan Date: Tue, 30 Dec 2014 12:03:35 +0000 (+0000) Subject: Change notify2.test to check that sqlite3_blocking_step() uses CPU more efficiently... X-Git-Tag: version-3.8.8~61 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8ab4b9e96459f756749edad0cfb2eb6faef771bc;p=thirdparty%2Fsqlite.git Change notify2.test to check that sqlite3_blocking_step() uses CPU more efficiently than sqlite3_step(), not that it results in greater overall throughput for any specific number of threads. FossilOrigin-Name: d904d29354a5ed85d33bafe4a7143f3c5ecee790 --- diff --git a/manifest b/manifest index 750bbbaad6..68e968d12e 100644 --- a/manifest +++ b/manifest @@ -1,5 +1,5 @@ -C Round\sall\sobject\ssizes\sthat\sgo\sinto\scomputing\sSQLITE_CONFIG_PCACHE_HDRSZ\sup\nto\sa\smultiple\sof\s8\sbytes. -D 2014-12-30T00:57:29.979 +C Change\snotify2.test\sto\scheck\sthat\ssqlite3_blocking_step()\suses\sCPU\smore\sefficiently\sthan\ssqlite3_step(),\snot\sthat\sit\sresults\sin\sgreater\soverall\sthroughput\sfor\sany\sspecific\snumber\sof\sthreads. +D 2014-12-30T12:03:35.117 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f F Makefile.in 40326b6d788007dd5e00587c54adcd2621832bb3 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23 @@ -755,7 +755,7 @@ F test/mutex2.test bfeaeac2e73095b2ac32285d2756e3a65e681660 F test/nan.test e9648b9d007c7045242af35e11a984d4b169443a F test/nolock.test 0540dd96f39b8876e3ffdd8814fad0ea425efeee F test/notify1.test 669b2b743618efdc18ca4b02f45423d5d2304abf -F test/notify2.test ce23eb522c9e1fff6443f96376fe67872202061c +F test/notify2.test 2ecabaa1305083856b7c39cf32816b612740c161 F test/notify3.test 10ff25cde502e72a92053a2f215d64bece4ef934 F test/notnull.test f8fcf58669ddba79274daa2770d61dfad8274f62 F test/null.test a8b09b8ed87852742343b33441a9240022108993 @@ -1234,7 +1234,7 @@ F tool/vdbe_profile.tcl 67746953071a9f8f2f668b73fe899074e2c6d8c1 F tool/warnings-clang.sh f6aa929dc20ef1f856af04a730772f59283631d4 F tool/warnings.sh 0abfd78ceb09b7f7c27c688c8e3fe93268a13b32 F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f -P 0f9e549643ab94b0465e6891384dd20506708a8f -R e296d2763d3effbc9c21b29aae15693b -U drh -Z 2369afc171a95fab3bda365a2e52134d +P b28ce75f2d3a6343dc20d581dc55afae89ab5efa +R 05d3fab766dc5317a84b8e8fc66a7683 +U dan +Z 9e6a15ccef1a8c8d1ccc67c36a60ea41 diff --git a/manifest.uuid b/manifest.uuid index 51d7bf7cd2..f0f3fc30da 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -b28ce75f2d3a6343dc20d581dc55afae89ab5efa \ No newline at end of file +d904d29354a5ed85d33bafe4a7143f3c5ecee790 \ No newline at end of file diff --git a/test/notify2.test b/test/notify2.test index 9e40ed695b..12c6a537ef 100644 --- a/test/notify2.test +++ b/test/notify2.test @@ -101,6 +101,8 @@ set sql $zSql # This loop runs for ~20 seconds. # set iStart [clock_seconds] + set nOp 0 + set nAttempt 0 while { ([clock_seconds]-$iStart) < $nSecond } { # Each transaction does 3 operations. Each operation is either a read @@ -128,6 +130,7 @@ set sql $zSql # Execute the SQL transaction. # + incr nAttempt set rc [catch { execsql_blocking $::DB " BEGIN; $SQL(1); @@ -154,13 +157,14 @@ set sql $zSql # returned "1". Otherwise, the invariant was false, indicating that # some malfunction has occurred. foreach r $msg { if {$r != 1} { puts "Invariant check failed: $msg" } } + incr nOp } } # Close the database connection and return 0. # sqlite3_close $::DB - expr 0 + list $nOp $nAttempt } foreach {iTest xStep xPrepare} { @@ -204,7 +208,9 @@ foreach {iTest xStep xPrepare} { for {set ii 0} {$ii < $nThread} {incr ii} { do_test notify2-$iTest.2.$ii { if {![info exists finished($ii)]} { vwait finished($ii) } - set finished($ii) + incr anSuccess($xStep) [lindex $finished($ii) 0] + incr anAttempt($xStep) [lindex $finished($ii) 1] + expr 0 } {0} } @@ -225,17 +231,36 @@ foreach {iTest xStep xPrepare} { } # The following tests checks to make sure sqlite3_blocking_step() is -# faster than sqlite3_step(). blocking_step() is always faster on -# multi-core and is usually faster on single-core. But sometimes, by -# chance, step() will be faster on a single core, in which case the +# faster than sqlite3_step(). "Faster" in this case means uses fewer +# CPU cycles. This is not always the same as faster in wall-clock time +# for this type of test. The number of CPU cycles per transaction is +# roughly proportional to the number of attempts made (i.e. one plus the +# number of SQLITE_BUSY or SQLITE_LOCKED errors that require the transaction +# to be retried). So this test just measures that a greater percentage of +# transactions attempted using blocking_step() succeed. +# +# The blocking_step() function is almost always faster on multi-core and is +# usually faster on single-core. But sometimes, by chance, step() will be +# faster on a single core, in which case the # following test will fail. # puts "The following test seeks to demonstrate that the sqlite3_unlock_notify()" -puts "interface helps multi-core systems to run faster. This test sometimes" -puts "fails on single-core machines." +puts "interface helps multi-core systems to run more efficiently. This test" +puts "sometimes fails on single-core machines." puts [array get anWrite] do_test notify2-3 { - expr {$anWrite(sqlite3_blocking_step) > $anWrite(sqlite3_step)} + set blocking [expr { + double($anSuccess(sqlite3_blocking_step)) / + double($anAttempt(sqlite3_blocking_step)) + }] + set non [expr { + double($anSuccess(sqlite3_step)) / + double($anAttempt(sqlite3_step)) + }] + puts -nonewline [format " blocking: %.1f%% non-blocking %.1f%% ..." \ + [expr $blocking*100.0] [expr $non*100.0]] + + expr {$blocking > $non} } {1} sqlite3_enable_shared_cache $::enable_shared_cache