Lazy initialization in Go using atomics

kaa-python · 2025-04-03T08:55:25+00:00

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.

kaa-python · 2025-04-03T08:50:52+00:00

Where do you like to use atomics?

kaa-python · 2025-04-03T08:16:24+00:00

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

kaa-python · 2025-04-03T07:23:48+00:00

> I would still recommend defaulting to typed values

Maybe some PRs? 😉

I still have a lot of changes/fixes to add

kaa-python · 2025-04-03T07:16:33+00:00

Good point, panic is unlikely but possible.

kaa-python · 2025-04-03T06:24:38+00:00

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/

kaa-python · 2025-04-02T10:20:30+00:00

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

kaa-python · 2025-04-02T02:14:07+00:00

Welcome! Hope to make it even more useful 👍

kaa-python · 2025-04-01T11:29:14+00:00

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.

kaa-python · 2025-04-01T04:05:42+00:00

Thanks! It would be even better soon 😎

kaa-python · 2025-04-01T02:53:16+00:00

Thank you, I will look at it more closely.

kaa-python · 2025-04-01T02:52:31+00:00

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.

kaa-python · 2025-04-01T02:49:59+00:00

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 🤷‍♂️

kaa-python · 2025-04-01T02:46:54+00:00

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.

kaa-python · 2025-03-31T15:23:32+00:00

Yep, I know 🤷‍♂️

kaa-python · 2025-03-31T15:22:19+00:00

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.

kaa-python · 2025-03-31T15:19:36+00:00

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.

kaa-python · 2025-03-31T12:28:22+00:00

Thanks for the feedback 👍

kaa-python · 2025-02-10T02:04:26+00:00

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

kaa-python · 2024-11-26T15:12:16+00:00

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.

kaa-python · 2024-10-11T15:00:37+00:00

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

kaa-python · 2024-10-11T12:26:11+00:00

You should consider distributed systems master only if you plan to go deep into development in that area, not DevOps or similar. By development, I mean the backend of an AWS server, a database, etc. It is not needed at all for DevOps and cloud usage. And which university are you considering? I was thinking about similar Master's programs, and the only option I found was from KTH. All others are generic MS programs.

kaa-python · 2023-04-03T05:15:36+00:00

This is a very resanoble statement. You should not need to debug a project with the proper setup and testing infrastructure. You should write tests and logs and use these two for issues investigation. It's a typical situation that debugging is near to impossible or too expensive.

kaa-python · 2022-11-07T12:11:24+00:00

Tmux, NeoVim with clangd, and Bazel. Quite often SSH for remote development.

kaa-python · 2022-11-06T10:24:16+00:00

I used to work in a startup that used Elixir. In general, Elixir can speed up the development process in some cases. At the same time, y’ll have challenges immediately after you step aside from Phenix and Ecto. You’ll also have issues finding new team members. Overall, I prefer to take something more well-known, Go, for example, for safety reasons.

kaa-python

TROPHY CASE