go performance refactoring learnings #126
Conversation
lainio
commented
Oct 4, 2023
lainio
commented
- fix links to previous blog post
- first draft
- better intro
- first draft
- part 1 language fixing
- review ready
- cover image
- release date
|
PR created by lainio |
|
PR created by lainio |
There was a problem hiding this comment.
Great text and really interesting topic(s)!
The usual comment: I would divide the text in two posts 😄 One for performance and other for readability and cross-reference to the other text when needed.
I added some comments where I think additional clarifications are needed.
Let's sync more online.
PS. Is the new PGO-feature https://go.dev/doc/pgo at all related or could it be commented in the text somehow
| --- | ||
|
|
||
| Since jumping on the OSS (Open Source Software) wagon, I have been learning | ||
| new things about software development and getting more proof to do something in |
There was a problem hiding this comment.
"getting more proof to do something in specific ways" is a bit hard to grasp
| attributes](https://en.wikipedia.org/wiki/List_of_system_quality_attributes) | ||
| during programming. They say you shouldn't sacrifice, for instance, readability | ||
| or maintainability for performance. You can write more readable code when you | ||
| know how compilers and underlying hardware work and execute **multi-discipline |
There was a problem hiding this comment.
what are these multi-disclipline engineering practices? is it explained earlier or in some of the chapters?
| title: "Image #:counter" | ||
| --- | ||
|
|
||
| Since jumping on the OSS (Open Source Software) wagon, I have been learning |
There was a problem hiding this comment.
The introduction is quite long. Think about the reader, what motivates him to read further? What there is to be gained by reading this blog?
| achieved **cross-domain engineering practices**. | ||
|
|
||
| In this post, I'll go through some fundamental Go tools and tricks you could use | ||
| to achieve *decent execution speed of your (Go) software and maintain or |
There was a problem hiding this comment.
It feels you are trying to cover both readability and performance in this text. It feels like the topics would deserve a dedicated blog each.
| to achieve *decent execution speed of your (Go) software and maintain or | ||
| increase its readability.* | ||
|
|
||
| # Perfect Code? |
There was a problem hiding this comment.
This chapter would be an excellent intro for the perf blog.
| Expressing things with the control-flow structures of imperative (or functional) | ||
| programming languages is more challenging – especially when the correctness of | ||
| the design should be verified. It seems that it’s easy to forget software | ||
| quality attributes during fast-phasing programming if we use tools that only |
|
|
||
| The `-benchmem` flag inserts two columns to benchmarking results: | ||
|
|
||
| ``` |
There was a problem hiding this comment.
It is a bit confusing that the sources for these functions are shown only after this chapter.
| Since jumping on the OSS (Open Source Software) wagon, I have been learning | ||
| new things about software development and getting more proof to do something in | ||
| specific ways. Two of my favorite 'things' At the *code level* are **readability** | ||
| and **modifiability**. The latter is a very old friend of SW architecture's |
| Go’s regexp implementation is known to be relatively slow, but if you think that | ||
| regexp needs its compiler and processor, it’s not so surprising. | ||
|
|
||
| The hand-optimized version of the Decamel function is almost ten times faster. |
There was a problem hiding this comment.
What exactly are the optimizations? What are the aspects that the reader should pay attention to in the code snippet below?
| > just enough -- trust abstraction layering. (See the rule #1.) | ||
|
|
||
| Next time you are writing something, think twice -- I do ;-) | ||
|
|
There was a problem hiding this comment.
I think a summary chapter would be a good addition. Just bullets that what did the reader just learned and how to utilize that info in their daily work.
|
|
||
| Practise has taught that software architecture must be expressed in various | ||
| notations; most are visual. For example, most of us can reason that a | ||
| well-grafted state-machine diagram must be faster than a code written our |
|
PR created by lainio |
|
PR created by lainio |
