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
