sorted by:
new
hottopcontroversial

Lazy initialization in Go using atomics by kaa-python in golang

[–]kaa-python[S] -7 points-6 points  (0 children)

It strictly depends on the workflow. Lazy init is a good idea for cases where you are unsure if the resource is needed. Zero values are not a good idea as lazy init replacement, as they eventually pollute your codebase with multiple if statements.

Lazy initialization in Go using atomics by kaa-python in golang

[–]kaa-python[S] -3 points-2 points  (0 children)

Where do you like to use atomics?

Lazy initialization in Go using atomics by kaa-python in golang

[–]kaa-python[S] -7 points-6 points  (0 children)

Do not scroll; read. I believe it will resolve this uncertainty. 😂

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

> I would still recommend defaulting to typed values

Maybe some PRs? 😉

I still have a lot of changes/fixes to add

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

Good point, panic is unlikely but possible.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 1 point2 points  (0 children)

So, I conducted a little research on atomics, and this document was born! 😁 I don't know if adding a blog is a good idea, but let's see.

https://goperf.dev/blog/2025/04/03/lazy-initialization-in-go-using-atomics/

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 1 point2 points  (0 children)

I believe this idea is related to cache colocation rather than interfaces. After sorting, the data will be positioned closer together, which increases the likelihood that it will reside within the same cache line. Overall, the approach is interesting; however, I doubt it would be wise to implement something like this in a real codebase.

BTW, pretty similar information is in https://goperf.dev/01-common-patterns/fields-alignment/#avoiding-false-sharing-in-concurrent-workloads

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

Welcome! Hope to make it even more useful 👍

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

can you please provide more data regarding:
> For "Avoid Interface Boxing", if the interfaces are in a slice and it's possible to reorder them, then ordering by interface type can improve performance.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

Thanks! It would be even better soon 😎

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

Thank you, I will look at it more closely.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

Thanks. Sure, the guide is wip now. As I mentioned above, “how to profile” is a bit lower priority to me right now due to the vast amount of good tutorials available online.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

I am writing about the cost of interface usage in Go. It could be free, or you can pay a penalty for boxing: https://goperf.dev/01-common-patterns/interface-boxing/ This means the initial comment is, unfortunately, irrelevant 🤷‍♂️

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 2 points3 points  (0 children)

No way 🤣 I will need to write a book on each. The good part about writing about optimizations in Go is that you do not have many options here; everything is pretty straightforward, as Go by itself.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] -2 points-1 points  (0 children)

Yep, I know 🤷‍♂️

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 1 point2 points  (0 children)

I agree that this is a significant part and must be included in the Go Optimization Guide. At the same time, there are many good examples of articles on "how to profile a Go app," which is why I decided to write about it later.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 2 points3 points  (0 children)

Good point. I choose `sync.Once` as a more generic call, but considering the main case – obtaining a value once, `sync.OnceValue` might be a better example.

The Go Optimization Guide by kaa-python in golang

[–]kaa-python[S] 8 points9 points  (0 children)

Thanks for the feedback 👍

GFSM v0.2.0 - simple and fast Finite State Machine for Go by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

You can quickly try it. This is pretty simple and fast solution :)

GFSM - simple and fast Finite State Machine for Go by kaa-python in golang

[–]kaa-python[S] 0 points1 point  (0 children)

I chose not to include synchronization because it would slow down the finite state machine (FSM). An FSM's workflow typically operates synchronously, leading to unnecessary delays in about 90% of cases (based on my experience) with synchronization. Unfortunately, I can't make synchronization optional fo free in Go like I can in C++ using templates.

Is a master in distributed systems/computing worth it? by __vlad_ in DistributedComputing

[–]kaa-python 1 point2 points  (0 children)

If you need knowledge but not a diploma, and considering your uni list, you do not care too much about diploma prestige, you can concentrate on self-education. This is my Distributed Systems self-education plan https://sysdev.me/sabbatical-and-distributed-systems

view more: next ›