On Mar 24, 2018, at 5:11 PM, Svyatoslav Mishyn <svyatoslav.mis...@gmail.com> wrote: > > just noticed that page generation of many of my repos is 0.001s.
The calculation for that is in the skin’s Footer code: [expr {([utime]+[stime]+1000)/1000*0.001}] In TH1, the utime and stime functions return microseconds, so + 1000 means “add one millisecond”, so that when dividing microseconds down to seconds with the subsequent arithmetic, the resulting value can never be lower than 0.001s. It would probably be more mathematically defensible to use + 500 instead to round to the nearest millisecond, but that might confuse people when people see that it claims to have run in “0.000s”, since it obviously did not run instantaneously. Another mathematically defensible change would be to report that the page generation took “less than” the reported amount of seconds. (Not “less than or equal to,” since a generation time of exactly 1000 µs would yield “0.002s” from the above calculation.) > And that result is identical for many web-pages, > only difference was for some /search request > and some heavyweight check-in pages. Your point? If we back out the “round up to next millisecond” arithmetic explained above, an “0.001s” generation time report means the actual wall time to build the page was somewhere under 1ms. On a 3 GHz CPU, a clock cycle is ~0.33ns, and many Intel CPU instructions do in fact take about 1 cycle. Of those that take multiple CPU cycles, you can often wave way the difference with pipelining and speculative execution. Thus, to a first approximation we have enough time to run about 3 *million* CPU instructions. The wonder of it all is not how Fossil can manage to construct a few kilobytes of HTML by using millions of CPU instructions, but that we’ve ended up in a world where we’re uncertain about whether millions of CPU instructions are sufficient to accomplish the task! > I compared page generation speed with some other Fossil repositories: > Fossil itself, SQLite, Tcl > using the same pages which are not strictly related to > repository size and age: like > /help, /sitemap, /stat, /wiki, /version?verbose > > and on these repos I got various timings after refreshing page, > while on mine always 0.001s You are presumably using a new or at least young repository, thus the various log(N) operations are using very small values of N, thus take very few CPU cycles to execute. Additionally, you are doing this on a system that is not under load, and which has hot RAM and mass storage caches. To this, you are comparing other repositories with large N, which probably have other concurrent users at any given time, and which are likely to have quite a few cache misses. Naturally your repository is “faster”. Put it under the same loads, and it will slow down as well. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users