RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova.jp
http://patshaughnessy.net/2013/10/24/visualizing-garbage-collection-in-ruby-and-python Pat Shaughnessyが、ブタペストで開催されたRUPY2013でのプレゼンの前半を自らのブログで紹介しています。 ガベージコレクタは、「ゴミを集める」という行為だけでなく、「新しいオブジェクトのためにメモリをあてがう。」「不要なオブジェクトを見つける」「不要なオブジェクトからメモリを取り戻す。」という、人間の心臓が血液を浄化するような働きをしている。 この簡単なコードサンプルを見ると、RubyとPythonの記述はよく似ているが、それぞれの言語の内部でのインプリの仕組みは違う。 1) Rubyのメモリ Rubyは、コードが実行される前に、数千のオブジェクトを先につくり、それをリンクされたfree listに置
プログラミング .NET Framework 第4版座談会でGCの話をしてきました - 銀の光と碧い空
というわけで、GCの話をしてきました。自分にとっては、ここまで言語機能というかRuntimeの中身について話したのは始めてかなあという感じです。 発売初日に買って、今日までGCの章だけずっと読んでいました。 参考文献です。 プログラミング.NET Framework 第4版 (プログラミングシリーズ) 作者: Jeffrey Richter,藤原雄介出版社/メーカー: 日経BP社発売日: 2013/10/10メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION) 作者: Sasha Goldshtein,Dima Zurbalev,Ido Flatow,サシャ・ゴルドシュタイン,ディマ・ズルバレフ,イド・フラトー,株式会社プロシステムエルオーシー出版社/メーカー:
最近のAndroid事情に対応した「OutOfMemoryErrorを知る」発表スライドを公開しました - ひつじのにっき
横浜Android and モバイルOS プラットフォーム部で発表した資料です。 資料はAndroidアプリ開発者をターゲットにまとめました。OutofMemoryErrorの発生原理とメモリ管理について最新事情を加味してまとめました(新版、なのはAndroid 1.xのころの発表が古いのにまだ参照されていたりで、さすがに最新事情に合わせて更新したかったのです)。 Androidアプリにおけるメモリ事情は(初期に比べたら)改善していますが、OpenCVなど画像処理の需要、高解像度対応を踏まえると依然として十分とは言いがたいユースケースもあります。そんな中でメモリ資源をうまく使うための指標となれば幸いです。 資料にもある通り書きかけの状態ですのでコメントやmentionなど「こんな情報があるから書き加えて」「ここ調べて」「こういうのがおすすめ」「ここ間違えてる！」というご意見いただければ嬉し
ImageViewとBitmap#recycle覚書 - hidecheckの日記
開発してるとActivityにBitmapを持たせたいことってよくある でもメンバで持ってると自前で解放しなくてはならない。 Bitmapのメモリ管理はネイティブ側で管理されてるので明示的に開放する必要がある。 マジで？って思ったので実験してみた 実験内容 以下のパターンでBitmapActivityがどのように変化するかを確認 実験1 ImageViewを持たないActivity 実験2 レイアウトでImageViewを持ったActivity 実験3 レイアウトでImageViewを持ち、メンバ変数でもImageViewをもつActivity 実験4 ImageViewを持ち、メンバ変数でBitmapをもつActivity 実験5 Bitmap#recycleの正しい使い方 使うアプリ こんな感じのアプリ 実験2〜4 MainActivity>BitmapActivity>（戻るキーで）
Javaはどのように動くのか～図解でわかるJVMの仕組み 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
JavaScript(V8)で避けるべき(だった?)クロージャの使い方 - kazuhoのメモ置き場
Grokking V8 closures for fun (and profit?) に、ほんの少しだけ触れられている話なんですが。 ごく最近まで V8 には、オブジェクトリテラルの中で関数リテラルを使った場合に非常に遅くなる(というかGCが多発する)問題があった。 たとえば、 function doit() { for (var i = 0; i < 1000; ++i) { for (var j = 0; j < 1000; ++j) { var o = { f: function () { return i + j; } }; } } } doit(); というコードを node-0.6.19 で実行すると、以下のように mark-sweep GC が大量に発生して処理に時間がかかっていることが分かる。 $ time /usr/local/node-0.6.19/bin/node -
エデンの園でおきたこと - steps to phantasien
有給を駆使し一足早くクリスマス休暇に突入、ヒャッホイ Ingress やるぜーと 意気込んでいた矢先ノロウイルスにやられダウンした。かなしい。鎮まれ俺の胃袋・・・ そんな腹痛日和の気晴らしとして今日は Garbage Collection Advent Calendar に参加してみることにしました。 Advent Calendar 初体験につきよくわかってないけど勝手に参加していいんですよね？ GC というとジェネレーショナルだのパラレルコンカレントだのといった話が目立ちがちだけれど、 現実の問題というかブラウザを相手にするとそれ以外の細々とした面倒が目につく。 GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
見えてきた「ECMAScript 6」。JavaScriptの生みの親が書く「Harmony of Dreams Come True」
見えてきた「ECMAScript 6」。JavaScriptの生みの親が書く「Harmony of Dreams Come True」 JavaScriptの標準仕様となっているのがECMAScriptで、最新バージョンは2009年12月に策定されたECMAScript 5th Editon。そして次のバージョンとなるECMAScript 6は、コード名「Harmony」もしくは「ES.next」や「ES6」と呼ばれています。 ECMAScript 6にはどのような機能が加わるのか、JavaScriptの生みの親であるBrendan Eich氏が、自身のブログに「Harmony of Dreams Come True」というエントリをポストし、その内容を紹介しています。PublickeyではEich氏の許可を得て日本語訳を掲載します。 （正確な翻訳に務めましたが、言語仕様やガベージコレクシ
__del__, gc, 循環参照, weakref
2010年11月22日公開 Python の __del__ メソッド、ガベージコレクタ、循環参照、そして弱参照についての解説と考察。 参照カウンタ __del__ __del__ の落とし穴 循環参照 __del__ の落とし穴 考察 __del__ を使わない 循環参照を確実に避けることはできる？ 弱参照 weakref モジュールを利用したハック いったいいつ __del__ を使うのか 参考文献 事項 参照カウンタ C/C++ では、malloc を使って確保したメモリや new で作成したオブジェクトについては、必ず対応する free / delete を呼ばなければならない。これを忘れるといつまでも解放されないメモリがプログラムの生存期間中居残ることになる。これをメモリリークと呼ぶ。メモリリークがあると、確保されたままになったメモリが OS や他のプロセスを圧迫して、システム全
それでもPHPにfinallyが必要な理由
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
ダイナミックObjective-C(104) プロパティ(4) - プロパティの属性
プロパティの話も4回目になった。今回は、プロパティの属性の話をしよう。実際にプロパティを使ったプログラミングをしていると、適切な属性の設定がとても大切だということに気づくだろう。 属性の文法 属性とは、プロパティを修飾するものになる。プロパティを設定したコードをコンパイルすると、それに合わせたアクセッサメソッドを作ってくれるのだが、このメソッドの種類や動作について、いくつかの細かい設定を可能にするのが属性だ。 文法としては、@property指示子の後に、括弧を付けて指定することになる。複数の属性を指定するときは、カンマで区切る。たとえば、次のコードではassignとreadwriteという2つの属性を指定している。 @property (assign, readwrite) NSString* value; どんな属性が定義されているのか、詳しく紹介しよう。 アクセサの名前と種類 プロパ
PHP: ガベージコレクション - Manual
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
mofmof.js とクラスベースOOP - latest log
クラスの使い方(初級) mofmof.js では mm("Hoge", { メソッド }) でクラス mm.Hoge を定義することができます。 mm("Hoge", { init: function(arg1, arg2) { this._arg1 = arg1; this._arg2 = arg2; }, method: function() { alert(this._arg1 + this._arg2); } }); var hoge = new mm.Hoge(1, 2); hoge.method(); new mm.Hoge(1, 2) のタイミングで init(1, 2) が呼ばれます init はコンストラクタと呼ばれ、 主に初期化に関わる処理を記述します mm.Hoge クラスのインスタンスを生成します alert(3) が実行されます クラス内部で使うプライベートなメソ
bmblog: iOSの古いプロジェクトをARC対応に変換する
よく聞かれるので、以下に軽くメモ。 iOS5から導入されたARC(Auto Reference Counting)。 retainやreleaseをOS任せに出来る。 いちいちdeallocを書かなくて良いなどソースコードの表記が簡潔にもなる。 一方、オブジェクトの型のチェックなどが厳しくなる。 iOS 5 for Developers - Apple Developer オフィシャルの詳細情報はdeveloper契約してから見るページにしかない様子。 Transitioning to ARC Release Notes (for ADC member only) Xcode4.2でプロジェクトを作成する場合はプロジェクト作成時に Use Automatic Reference CountingをチェックすることでARCを使うことができる。 一方、それ以前のXcodeで作った
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
Cocoaの素、Objective-Cを知ろう － ＠IT
Objective-C初心者のための入門連載です。Objective-Cとは何かの基礎知識から、さまざまな基本構文／文法（変数、データ型、nil、配列、プロパティ、アクセサ、クラス、スーパークラス、ルートクラス、サブクラス、ポインター、メソッド、インスタンス、リンク、ラッパークラス、コンパイラディレクティブ、id、メッセージ式、文字列操作、forなどの繰り返し（ループ）、列挙子、ディクショナリ（連想配列）、高速列挙、オブジェクト指向、継承、プロトコル、多重採用、セレクター、クラスクラスター、カテゴライズ、カテゴリ、メモリ管理、ガベージコレクション、参照カウンターなど）を、書き方が分かる豊富なサンプルコードとともに解説します。
PyPy における Python のパフォーマンスチューニング
これは PyPy Advent Calendar の記事です。PyPyのコアディベロッパーである "Maciej Fijalkowski" 氏のブログ "Analysing python's performance under PyPy" の抄訳+αです。 Python の一般的なパフォーマン解析のモデルは、"プロファイラを実行して、ボトルネックを探し出し、それを最適化するか C で書き直す" ことです。しかし PyPy ではこのアプローチだけでは不十分です。なぜなら、 多くの大規模アプリケーションで、プロファイラはフラットです: PyPy のトランスレーションツールチェーン、Twisted、モダンな Web サーバ等が良い例です ボトルネックを発見したとしても、それが特定の関数内でのみ遅いのか、複数の関数が関係しているのか明確になるわけではありません。どうすれば遅くて、どうすれば速くなる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
パフォーマンスを意識した Java コーディング #渋谷java
