felixge

7 ms·

31.
by felixge 3y ago
I'm not very familiar with Objective C and Swift, so this might not make sense. But JS used to have a similar problem with async/await. The v8 engine solved it by walking the chain of JS promises to recover the "logical stack
32.
by felixge 3y ago
First of all, I think the .eh_frame unwinding y'all pioneered is great. But I think you're only thinking about CPU profiling at <= 100 Hz / core. However, Brendan's article is also talking about Off-CPU profiling, and
33.
by felixge 3y ago
AFAIK Go’s spec allows relocating objects. The door towards a moving GC is kept open.
34.
by felixge 3y ago
Go doesn't have an instruction (execution) or function call tracer. Go's tracer is primarily tracing scheduler events. So maybe the term scheduler tracer should have been used? Anyway, using the term "execution tracer" i
35.
by felixge 3y ago
> but if it really is 1-2% that'd be totally worth it in many cases As one of the people who worked on the optimizations mentioned in the article, I'm probably biased, but I think you can expect those claims to hold outside of
36.
Go Memory Metrics Demystified(datadoghq.com)
3 points by felixge 3y ago|0 comments
37.
by felixge 3y ago
I’m skeptical about the numbers reported for Go, they seem too low. Maybe it’s caused by using Fprintf?
38.
by felixge 3y ago
Well said. But how much finite time are we talking about (for writes to become visible)? Does it differ between architectures? Can there be extreme edge cases?
39.
by felixge 3y ago
I guess I’m less worried about the atomic nature of the operation and more about the way the writes become visible. That seems to be entirely hardware dependent?
40.
by felixge 3y ago
Yeah, but there is no guarantee that a write of one goroutine will eventually become visible to other goroutines. So in practice the runtime expects stronger guarantees.
41.
by felixge 3y ago
The Go runtime has quite a few places where it assumes atomic load/store behavior of int sized words as well as the eventual propagation of the stores. I always get a little anxious when looking at such code. But it seems to work well
42.
by felixge 3y ago
I suspect every JVM heap alloc is implemented by doing an alloc in Go. The JVM references to the object are pointers in the Go VM. So no special magic is needed. When the Go VM stops referencing an object, the Go GC will collect it.
43.
Debug Go Request Latency with Datadog's Profiling Timeline(blog.felixge.de)
3 points by felixge 3y ago|0 comments
44.
by felixge 4y ago
> we were just testing Datadog Continuous Profiling Felix from Datadog here :). We'd love to hear your thoughts on our profiler if you're willing to share them. My e-mail is in my profile. PS: Congrats to Ryan, Dmitry and team
45.
FlameScope for Go(blog.felixge.de)
3 points by felixge 4y ago|0 comments
46.
Go Arm64 Function Call Assembly(blog.felixge.de)
3 points by felixge 4y ago|0 comments
47.
Reducing Go execution tracer overhead with frame pointer unwinding(blog.felixge.de)
100 points by felixge 4y ago|8 comments
48.
by felixge 4y ago
I would love this too, and looked into building an extension for it a few years ago. IIRC the main challenge was that many features such as row level security are built straight into the current query executor, making it difficult to build
49.
by felixge 4y ago
Having written lots of advanced SQL (tons of CTEs, window functions, user defined aggregates, json manipulation, etc.) in my previous job, this looks really promising. The main issue I encountered while playing with it is that the ordering
50.
by felixge 4y ago
The main difference is that you get a timeline (flame chart) rather than flame graph. This allows you to understand the order in which operations are taking place. You also get walltime (instead of CPU time), so you can debug Off-CPU perfor
51.
by felixge 4y ago
> He notes the performance & scalability issues already noted here by other commenters. Go 1.19 has made some improvements in this regard [1]. But yes, profiling all goroutines does not scale to programs that use more than perhaps 10
52.
by felixge 4y ago
Capturing a consistent snapshot of all goroutines requires stopping the world. However, this can be very quick as the GC relies on the same mechanism. The bigger problem is capturing the stack traces for all goroutines. Rhys added a patch t
53.
by felixge 4y ago
Sorry for the confusion :). I'm the author of both tools and was also considering to build the new functionality into fgprof since the data capturing approach is very similar. Anyway, if you found fgprof useful, I think fgtrace could b
54.
by felixge 4y ago
haha - certainly not in production, at least not with my hacky code here :)
55.
by felixge 4y ago
I'm the author of fgtrace, happy to answer any questions :). I've also posted a few more comments in this twitter thread: https://twitter.com/felixge/status/1571850160358965249
56.
Fgtrace – The Full Go Tracer(github.com)
117 points by felixge 4y ago|13 comments
57.
by felixge 4y ago
True! But it's also worth noting that those contributions are capped in Germany. This is different from other EU countries such as Portugal. For pension the cap is ~85k. For public health insurance is ~58k EUR, but you can opt out of t
58.
by felixge 4y ago
Yup. But that's marginal tax rate. Average tax rate for e.g. 150k EUR income is 37.8%. See https://www.bmf-steuerrechner.de/ekst/eingabeformekst.xhtml
59.
by felixge 4y ago
Agreed. A while ago I looked into hacking something like this into plv8. You'd be able to do something like: SELECT * FROM js_query('...'); Where the query is a JS snippet that has access to low level access methods, e.g.:
60.
Profiling Improvements in Go 1.18(felixge.de)
1 points by felixge 5y ago|0 comments

More ›