Go言語のスタックとヒープ
GoCon 2013 Autumn で「Go言語のスタックとヒープ」という発表をしました。 資料はこちら： http://goo.gl/s6at62 スライドだけでは分かりにくい部分もあるので、ブロク記事として以下にも記しておきます。(この記事を読めば、スライドは読まなくてOKなはず) スタックとヒープについて 実行時に動的にメモリを確保する領域として、スタックとヒープがある。 スタックメモリは関数のコールスタックを格納していて、ローカル変数、引数、戻り値もここに置かれる。 スタックのPushとPopは高速なので、オブジェクトをスタックメモリに確保するコストは小さい。ただし関数を抜けてスタックがPopされると解放されるので、関数の寿命を超えてオブジェクトは生存できない。 一方のヒープメモリは、コールスタックとは関係ないので、関数スコープに縛られずにオブジェクトを確保しておける。ただし空き領
Goでアロケーションに気をつけたコードを書く方法 : DSAS開発者の部屋
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
Stack vs heap allocation of structs in Go, and how they relate to garbage collection
I'm experiencing a bit of cognitive dissonance between C-style stack-based programming, where automatic variables live on the stack and allocated memory lives on the heap, and Python-style stack-based-programming, where the only thing that lives on the stack are references/pointers to objects on the heap. As far as I can tell, the two following functions give the same output: func myFunction() (*M
Escape Analysis and Stack Allocation on Go lang 1.2 レシーバ編 - fousの日記
最近、Go言語にいろんな意味ではまっているので、調べたメモpart2。 前回のやつは色々と中途半端で間違っていたので、書き直し+go 1.2開発版 (go version devel +f1545db4a9c4)で実験。 最終版ではないので、今後もぼちぼち修正＋更新するかもしれません。 Introduction Go言語の特徴として、スタック領域とヒープ領域を区別しないという特徴がある。 そのため、C言語初心者がやるような、こんなプログラムを書いてもよい。 package main import "fmt" func main() { var a1 *int = call1() fmt.Printf("value = %d", *a1) } func call1() *int { var b1 int = 10 return &b1 } とはいえこれは、プログラマが明示的には区別しないとい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
