Also, Chromium is not twice as slow, in fact 991 ns against 894 ns, is a difference of 7 nanos…. shorter than most cache reads. It is this sort of evidence that should be a red flag that your benchmark is broken.
Further, for things like http, it could be simply that Chromium sends more headers - the server has to process them… You should start by recording the actual bytes sent by the browser - the browser development tools can be used to inspect this. It could also be that one or the other is using http2 vs http - again, use the browser tools to make sure you are comparing the same thing. You can also run your test using ‘curl’ as a third data point. > On Apr 29, 2025, at 9:52 AM, christoph...@gmail.com > <christophe.mees...@gmail.com> wrote: > > > Here is a minimal program that I tried out: https://go.dev/play/p/Rp03LxuvDVw > . Note that it measures the duration of w.Write(msg). > > On my local host I displayed the web page http://localhost:8080/firefox with > Firefox, and http://localhost:8080/chromium with chromium. I don’t have > chrome installed. My computer is "idle", as far as I can tell. > > Here are four requests by chromium: > > url: /chromium duration: 2.5µs > url: /favicon.ico duration: 1.128µs > url: /chromium duration: 2.334µs > url: /favicon.ico duration: 991ns > url: /chromium duration: 2.568µs > url: /favicon.ico duration: 1.143µs > url: /chromium duration: 2.904µs > url: /favicon.ico duration: 1.654µs > > > Here are four requests by firefox on the same host in the exact same > condition: > url: /firefox duration: 1.094µs > url: /firefox duration: 1.979µs > url: /firefox duration: 894ns > url: /firefox duration: 1.125µs > > > I’m aware that I use the wall time which is not OK for benchmarks. I just > want to understand why it takes so long, and why is chromium twice slower ? > > Is there a scheduling switch just in the w.Write(msg) or time.Now() ? > > My CPU frequency is only 0.80Ghz showing that it’s not doing much. > > > > Le mardi 29 avril 2025 à 14:05:40 UTC+2, Robert Engels a écrit : >> Hi. Unless you provide a standalone test program it will very difficult for >> anyone to assist you. >> >>> On Apr 29, 2025, at 5:03 AM, christoph...@gmail.com <> >>> <christoph...@gmail.com <>> wrote: >>> >>> >> >>> More strange result. >>> >>> With Firefox, the time measured with time.Since is 55μs on average, and >>> with Chromium it’s on average 200μs but with a big jitter. It’s not the OS >>> (Ubuntu 2.24LTS) load that changes as both browsers are running side by >>> side. How can the ServeHttp processing time change (~ x4) depending on the >>> browser ? >>> >>> >>> >>> Le lundi 28 avril 2025 à 18:28:25 UTC+2, christoph...@gmail.com <> a écrit : >>>> I have created web site with a middleware measuring the execution time of >>>> requests using the time.Since(start) method. It is thus using the wall >>>> time. >>>> >>>> I see that the execution of the ServeHttp() is around 60μs. The handler is >>>> a function that simply renders the login page that I benchmarked to use at >>>> most 1μs. >>>> >>>> The time difference seams huge. The server is idle and receiving only one >>>> request at the time. I know that measuring execution time with a wall >>>> clock on a time sharing system is not a great, but I have 8 cores and they >>>> are mostly idle. I apparently don’t have a better method. >>>> >>>> I also saw a big jitter which was reduced by adding the instructions >>>> >>>> runtime.LockOsThread() >>>> defer runtime.UnlockOsThread() >>>> runtime.GOMAXPROCS(1) >>>> >>>> But I still see the big execution duration. >>>> >>>> Unfortunately, I can’t benchmark the ServeHttp() method has the object is >>>> complex (db, etc.). >>>> >>>> Is there a more precise way to measure the execution time Such big values >>>> don’t seam very accurate. >>> >>> >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts...@googlegroups.com <>. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/1b79e5c8-3c2c-4b43-b24e-16252dfdf3cdn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/1b79e5c8-3c2c-4b43-b24e-16252dfdf3cdn%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/e4c1ce28-7a2e-4d96-a9d1-5f7dd482ba90n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/e4c1ce28-7a2e-4d96-a9d1-5f7dd482ba90n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2792272C-A672-435A-A62C-8C62963B0E1B%40ix.netcom.com.
