felixge

10 ms·

61.
Connecting Go Profiling with Tracing(felixge.de)
6 points by felixge 5y ago|0 comments
62.
by felixge 5y ago
> Go will not inline a function that exceeds complexity metrics True, but: > and one of those metrics is whether the function contains a range statement. You will get a real heap-allocated closure invocation on each loop. I think this
63.
by felixge 5y ago
As with everything, it depends. I've implemented a large system managing billions of records using exactly this approach of cutting out a lot of boilerplate in the application layer. The most important thing is to be pragmatic. This ap
64.
by felixge 5y ago
The context of this article is profiling, not error handling.
65.
Stack Traces in Go(github.com)
17 points by felixge 5y ago|2 comments
66.
by felixge 5y ago
Yup, there is an upstream issue to improve this: https://github.com/golang/go/issues/44920 FWIW I'm planning to work on the problem from downstream as well by adding more docs here: https://gi
67.
by felixge 5y ago
Very interesting points about mutex profiles. When you say fast path, do you mean spin locks? For analyzing I/O via perf and looking at kernel stacks, I'm surprised that would work. I'd think that perf will not show you much
68.
by felixge 5y ago
Yeah, decent sampling for requests that last 10s of ms seems absolutely feasible with this approach, unlike the current setitimer(2) stuff. I'm really looking forward to taking it for a spin soon and see how far the sampling rate can b
69.
by felixge 5y ago
I think this is great work. Hopefully this can motivate upstream to reconsider the proposal for it. In the long run I don't think anybody wants to run with a forked version of Go for better profiling. > The ability to monitor go pro
70.
by felixge 6y ago
Lovely article. The symbolic checker approach is awesome. It seems trivial/simple in retrospect, but what a powerful testing approach for this problem!
71.
by felixge 6y ago
Thank you for the kind words! This is great motivation to continue writing about this stuff : )
72.
by felixge 6y ago
Thanks! Credit should also go to my employer Datadog. They allowed me to spend some time on this and make it available to the public!
73.
by felixge 6y ago
OP here. This is my attempt to document this profiler in Go based on my own research. As far as I can tell there is not much information about it out there. Happy to answer any questions.
74.
Block Profiling in Go(github.com)
148 points by felixge 6y ago|8 comments
75.
CSV Boilerplate for Go(felixge.de)
1 points by felixge 6y ago|0 comments
76.
by felixge 6y ago
This sounds great! That being said, I wonder how well this would work out for smaller projects. Spotify uses a very similar model, and from what I hear, lesser known artists make very little money on their platform.
77.
fgprof – The Full Go Profiler(github.com)
2 points by felixge 6y ago|0 comments
78.
by felixge 6y ago
I love PostgreSQL history, so this was tons of fun to read me for me. While reading, I also ended up highlighting and sharing some of my favorite parts on twitter: https://twitter.com/felixge/status/127261396521913
79.
by felixge 7y ago
I love SQLite, but I'd be curious how you were able to saturate an NVMe drive with it. Were you doing the inserts in large batches? Saturating an NVMe drive requires writing with very large block sizes or very high queue depths.
80.
by felixge 7y ago
That doesn't seem to help on macOS. I suspect you're on Linux?
81.
by felixge 7y ago
Just put together a naive version of wc in Go and got similar perf gains over the wc that ships with macOS. That being said, unlike the OP, I don't think it means anything as wc is likely supporting more features than my program.
82.
Why Explain Analyze Runs 60x Slower on Docker for Mac(twitter.com)
6 points by felixge 7y ago|0 comments
83.
by felixge 7y ago
A tool like would be a wonderful addition to the PostgreSQL ecosystem! That being said, this tool won't work well for anything but trivial queries. PostgreSQL query plans have many quirks around CTEs, Loops, etc. that cause problems wh
84.
by felixge 7y ago
Don't you have to spend > 50% of your time in Bulgaria in order to be considered a tax resident there? I suspect a lot of the "too good to be true" tax evasion stories in this thread depend on lying about your true place o
85.
by felixge 7y ago
SQL isn't the problem IMO. The problem is that the implementation we're using (PostgreSQL) is a row-store which is indeed more optimal for the kind of operations you mention. However, SQL isn't limited to row-stores. There ar
86.
by felixge 7y ago
Yup, that would reduce write IOPs but increase the latency for making the data available to our users.
87.
by felixge 7y ago
In my experience yes. Example: We struggled with some read-queries taking a long time when aggregating over millions of rows. To solve this, we used triggers to pre-compute aggregate groups in real-time during write, which allowed us to eas
88.
by felixge 7y ago
> 1: Never add a column with a default value This only applies to Postgres versions < 11. See https://blog.2ndquadrant.com/add-new-table-column-default-va... which was released after this article was written.
89.
by felixge 8y ago
In the category of SQL databases, it certainly is. I mean it's not called LiteDB for a reason I suppose ;).
90.
by felixge 8y ago
About registration: Do you really think it's important? I had two recent trips to Moscow where I was staying at Airbnbs and the hosts refused to register me. I was unable to find another way to register and decided to risk it. Nobody a

More ›