The point is that if you are timing “so much” that a 1-2 % overhead (so you
must have tons of very small operations) matter to throughput - sampling will
still capture enough that a representative event will be recorded.
Still, optimizing time.Now() is always a good idea but I am guessing much
Why not use the TSC timer for your timings, and convert TSC cycle times
into durations during
post-run analysis?
On Thursday, 29 April 2021 at 04:04:58 UTC+1 Pure White wrote:
> Hello,
> We are doing heavily tracing, and for each func we need to get the time,
> so that’s why I’d like to
Anyway, I think we are all consensus to optimize `time.Now`, Ian and me both
sent pr for this. Thanks for everyone taking part in.
在 2021年4月29日 +0800 AM11:58，Robert Engels ，写道：
> If you are timing so short operations that the overhead is 1-2%, just time
> every 1000 calls - reduces the overhead
Thanks for your suggestion. But in that way, we are not able to capture the
abnormal call.
在 2021年4月29日 +0800 AM11:58，Robert Engels ，写道：
> If you are timing so short operations that the overhead is 1-2%, just time
> every 1000 calls - reduces the overhead to a minimum. Normally makes no
>
If you are timing so short operations that the overhead is 1-2%, just time
every 1000 calls - reduces the overhead to a minimum. Normally makes no
difference if the operations are that short. Similar to how benchmarking works
- time the total and divide by the number of operations.
> On Apr
Hello,
We are doing heavily tracing, and for each func we need to get the time, so
that’s why I’d like to optimize this.
在 2021年4月29日 +0800 AM12:11，Ian Lance Taylor ，写道：
> In the meantime we both sent speedups for time.Now. I measured
> time.Now as taking about 30 nanoseconds per call before the
In the meantime we both sent speedups for time.Now. I measured
time.Now as taking about 30 nanoseconds per call before the speedup,
and you measured it as taking about 40 nanoseconds per call before the
speedup. That makes me wonder about your code: if a 40 nanosecond
function is taking 1% to 2%
Wow, sounds great!
Really looking forward to this feature!
在 2021年4月28日 +0800 PM12:22，Ian Lance Taylor ，写道：
> On Tue, Apr 27, 2021 at 8:26 PM Pure White wrote:
> >
> > I think this is a good idea. But I suppose this will meet the same problem
> > I have met syscall package is outside of the
On Tue, Apr 27, 2021 at 8:26 PM Pure White wrote:
>
> I think this is a good idea. But I suppose this will meet the same problem I
> have met syscall package is outside of the runtime.
We can introduce hooks into the runtime that are only for the standard
library, because we know exactly
I think this is a good idea. But I suppose this will meet the same problem
I have met syscall package is outside of the runtime.
在2021年4月28日星期三 UTC+8 上午12:54:25 写道：
> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a case
On Tue, Apr 27, 2021 at 9:59 AM Michael Pratt wrote:
>
> Oops, I should say the syscall package could do this. x/sys/unix has the
> extra complexity of not being tied to a Go release.
It's a good idea, although I'll note that the syscall package does not
currently define ClockGettime.
I think
Oops, I should say the syscall package could do this. x/sys/unix has the
extra complexity of not being tied to a Go release.
On Tue, Apr 27, 2021, 12:53 Michael Pratt wrote:
> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a
I'm not sure if calling through the VDSO is the best solution to this
specific issue, though it does sound like a case that would certainly
benefit.
Regardless, one fairly clean way we could support this would be to make
x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
than
https://blog.cloudflare.com/its-go-time-on-linux/
A bit old, but still relevant.
Also https://github.com/dterei/gotsc may be useful depending on your
requirements.
On Tuesday, 27 April 2021 at 16:54:38 UTC+1 manlio@gmail.com wrote:
> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2
On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo
wrote:
> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
> scritto:
>
>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo
>> wrote:
>> >
>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>> scritto:
>> >>
Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
scritto:
> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo
> wrote:
> >
> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
> scritto:
> >>
> >> So I really want to know what is the right way to do
On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo wrote:
>
> Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha scritto:
>>
>> So I really want to know what is the right way to do vdso call outside
>> runtime?
>>
> What about using a different function instead of time.Now, and using
Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha scritto:
> Hi all,
>
> I'm trying to get time using `CLOCK_REALTIME_COARSE` and
> `CLOCK_MONOTONIC_COARSE` for performance reasons, and need to use vdso call
> by hand-written assembly code. That is, I want to reimplement
18 matches
Mail list logo
