<p>I have been profiling a project I've been working on and have found a lot of my calls or rather the majority of my long running calls equate to the following:</p>
<p> </p>
<ul>
<li>String / Int conversions</li>
<li>Slice / Map Growth & allocations</li>
<li>What I presume is runtime & GC ?***</li>
</ul>
<p> </p>
<p>My questions:</p>
<p> </p>
<ul>
<li>What is the most efficient way to convert a string to int and int to string (knowing that it is probably best to keep everything all one type) ?</li>
<li>What (from looking at the attached cpuprofile) do you notice in the cpu profile output?</li>
<li>To address my *** point, what is happening during the runtime calls? I will be diving into the source later to try to make sense of the calls being made but wonder if someone has a high level explanation off hand.</li>
</ul>
<p> </p>
<p><a href="http://i.imgur.com/kdpwu9f.png" rel="nofollow">Pprof web output (imgur)</a></p>
<hr/>**评论:**<br/><br/>1lann: <pre><blockquote>
<p>What is the most efficient way to convert a string to int and int to string (knowing that it is probably best to keep everything all one type) ?</p>
</blockquote>
<p>I don't think that's something people usually worry about. The strconv library should be fine. If Go's performance isn't good enough, perhaps you should consider using C, C++ or Rust.</p>
<blockquote>
<p>To address my *** point, what is happening during the runtime calls? I will be diving into the source later to try to make sense of the calls being made but wonder if someone has a high level explanation off hand.</p>
</blockquote>
<p>I don't know the internals of Go that well, but I believe that majority of it would just be the GC which is a mark-and-sweep GC, and the scheduler which determines which goroutines are running.</p>
<p>Ideally you should just either decrease your allocations to improve GC performance, or understand how Go's escape analysis works, to take advantage of it and limit allocations into the heap. You should also think about whether or not your program is repeating any operations that can otherwise be cached between requests, or use a different data structure to reduce time complexity.</p>
<p>Take my words with a grain of salt though, I don't understand the internals of Go that well and what I've said is based on what I've read, and a bit from experience.</p></pre>nastus: <pre><p>Thanks for the reply it is much appreciated! What you're saying makes sense, I know I probably have a ton of things wrong with my code - as I'm new to go - but the performance isn't bad I just don't know what the threshold between "good" and "bad" really is. E.g. Obviously a function that benchmarks are 100ns/op is fast but what about those are 20,000ns/op is that still considered good? I have much to learn :)</p></pre>dericofilho: <pre><p>I couldn't find, but there's a video version of these slides. </p>
<p><a href="http://gotocon.com/dl/goto-chicago-2016/slides/FrancescCampoyFlores_GoToolingInAction.pdf" rel="nofollow">http://gotocon.com/dl/goto-chicago-2016/slides/FrancescCampoyFlores_GoToolingInAction.pdf</a></p>
<p>It's a nice walk through on how to improve your code. </p></pre>dericofilho: <pre><p>The video</p>
<p><a href="https://m.youtube.com/watch?v=uBjoTxosSys" rel="nofollow">https://m.youtube.com/watch?v=uBjoTxosSys</a></p></pre>nastus: <pre><p>Thanks!!</p></pre>
![](https://static.golangjob.cn/static/img/banner.png)