プログラマーが知っておくべき「PC内部の通信速度」
PCは計算を担当するCPUや一時的なデータ保存のためのメモリ、HDDやSSDなどの長期保存のためのストレージなどが相互にデータをやり取りしながら動作しています。「Latency Numbers Every Programmer Should Know」というサイトにPC内部のそれぞれの通信速度がまとまっています。 Numbers Every Programmer Should Know By Year https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html 以下のように色分けされたブロック(■)の数でそれぞれの速度が表されています。 PC内部で超高速な通信を行っているのがCPUとL1・L2などのキャッシュです。これらのキャッシュはCPUとメモリの速度差を埋めるためにCPUに搭載されています。詳細な役割は
DOMAIN ERROR
ドメインウェブの設定が見つかりません 考えられる原因 ドメインウェブの設定がまだ行われていない。 ドメインウェブの設定がまだ反映されていない。(反映には数時間～24時間かかることがあります) ドメインウェブ・DNSの設定が誤っている。 アカウントが存在しない、契約が終了している、削除されている。
iPhoneアプリ開発時のメモリ管理で気をつけること(マルチスレッド編) - A Day In The Life
以前iPhoneアプリ開発時のメモリ管理で気をつけることという記事を書いたのですがマルチスレッド時のメモリ管理に関して全く触れてなかったのでまとめてみました。 NSAutoreleasePool はスレッドごとに作成する 処理を別スレッドで実行する場合、スレッドごとに NSAutoreleasePool が必要になります。NSAutoreleasePool の作成を忘れるとメモリリークします。 以下のように main 関数から Sample クラスのインスタンスを生成してメソッドを呼び出している場合、シングルスレッドの場合とマルチスレッドの場合で NSAutoreleasePool の作成タイミングが異なります。 @interface Sample { } - (void)hoge; - (void)foo; - (void)bar; - (void)baz; @end int main(
今感じていること iPhoneアプリでHTTP通信を頻繁に行っているとメモリ使用量が…
リークしている訳でもないし…Instruments見ながら数日悩んでいたら、「CFData(store)」てのが異様に増えているなーということに気づいて。 CFData Memory Problem - iPhone Dev SDK Forum アプリケーションごとにキャッシュを作っているので、これを明示的にクリアしてあげないと行けなかったと。こんな感じで NSURLCache *sharedCache = [[NSURLCache alloc] initWithMemoryCapacity:0 diskCapacity:0 diskPath:nil]; [NSURLCache setSharedURLCache:sharedCache]; [sharedCache release]; こちらにも詳しく書いてありました。 Cocoaの日々: [iOS] UIWebView のキャッシュ調査
メモリ管理 - かみやんの技術者ブログ
iPhone開発で、メモリ管理の基礎を社員に伝えることが増えてきたので、エントリとして書こう。 Objective-C基礎 メモリ管理の前にObjCの基礎として、メソッド呼び出しの話。 クラスのインスタンスaがmethodAをコールするときは、 [a methodA] と書く。このとき、aがnilだったときは、エラーではなく、コールされない。methodAに戻り値があるときは、それは、0やnilやNOが返る。ObjCでは、 void dealloc { if(a!=nil){ [a release]; } [super dealloc]; } は、気持ち悪いので、nilチェックはやめましょう。 なお、ObjCでは、動的にメソッドを差し替えることができ、コールの度にメソッドが存在しているかも確認しています。そのため、LL言語(ライトウェイト言語、スクリプト）のように柔軟な記述が可能です。そし
MacのFirefoxが重い！超軽快になるカスタマイズ方法3つ | Web活メモ帳
ブラウザはずっとChromeを使っていたのですが、 Mountain Lionにしてからクラッシュで使い物にならなくなりました。 何のブラウザが使いやすいかな・・と思って色々試してみましたが、結局Firefoxに戻りました。 しかし、重いですね。。。 これを解決するためのTipsを探したのでシェアします。 どなたかの参考になれば幸いです。 1.about:configをいじる Firefoxのアドレスバーに「about:config」と打ち込んでEnterを押すと、 設定画面に切り替わります。 設定画面から以下のように設定を変更してください。 network.http.proxy.pipelining→「true」 browser.cache.memory.enable→「true」 network.http.pipelining.maxrequests→「8」 network.http.
iOS Viewライフサイクルまとめ、iOS6での変更点 – Zero4Racer PRO Developer's Blog
TwitterでViewライフサイクルについて話題になったので、まとめてみました。 @tomohisa @gaolay @replicantnexus6 @t_okada これまではiOS5では呼ばれてましたね。5ではwillUnloadっていう使いドコロのわからないメソッドも追加されてそれも呼ばれてましたし。 — kishikawa katsumiさん (@k_katsumi) 9月 20, 2012 シングルビューの動作 こちらが基本となります。よく勘違いされているのは、ViewDidUnloadは、いつもViewが閉じるときに呼ばれるというものですが、これは間違いで、通常、ViewDidUnloadは呼ばれません。 モーダルビューが呼ばれたとき モーダルビューが呼ばれたときの注意点は、裏にあるビューは、一度UIWindowから削除されて、ViewDidDisappearが走るという点
releaseの使いどころ : As Sloth As Possible
俺もメモリ管理を間違えて頻繁にアプリを落としてしまうゆとりプログラマなのであんまり偉そうなことも言えないのだけど、「releaseの使いどころ。メモリの辺りがどうしてもわからない。」を読んでいくつか思ったところがあるので書いときます。 「何度もinit」はしない 既に確保されているハズの変数を二度initするのはメモリリークだよね？ 解放されている変数は、 if (obj == nil) では判別できないのだろうか。 ボタン押下時などに、同じロジックを走ることが多くて、何度もinitをしてしまうことが多いのだが。。。。 具体的なコードを見てないので間違ってるかもだけど、多分これ「何度もinitしちゃう」じゃなくて「開放してないオブジェクトを参照してる変数に、何度も新しいオブジェクトをつっこんじゃう」ってことだと思って話を進める(そうすると、どこからも参照が辿れないのにメモリが開放されてない
[iPhone] UIWebView のリリース前に delegate に nil をセットする必要がある | Sun Limited Mt.
UIWebView のインスタンスに delegate を指定している場合は以下のように release する前に delegate に nil をセットする必要があります。 - (void) viewDidLoad { webView = [[UIWebView alloc] init]; webView.delegate = self; .... } - (void)dealloc { webView.delegate = nil; [webView release]; } アップルのマニュアルにも以下のように書かれています。 Important: Before releasing an instance of UIWebView for which you have set a delegate, you must first set its delegate property to
メモリ管理を理解する（前編）
メモリ管理を理解する（前編）：Cocoaの素、Objective-Cを知ろう（7）（1/2 ページ） iPhone用アプリケーション開発で注目を集める言語「Objective-C」。C++とは異なるC言語の拡張を目指したこの言語の基本を理解しよう（編集部） あらゆるアプリケーションは、システムのメモリ上に展開されて動作します。 メモリは限られた資源なので、アプリケーションは資源を無駄に消費しないよう自己管理しながら動作する必要があります。この動作を実現するのが、開発者によるメモリ管理の実装です。 新しく登場した言語のなかにはメモリ管理が自動で行われる（言語のエンジン部分で暗黙的にメモリ管理がされている）ものが多いため、開発者がメモリ管理を意識することが少なくなっています。 実際、Objective-Cでも、Objective-C 2.0から（Mac OS X 10.5 から）はガベージコレ
viva Cocoa / Objective-C 入門
Objective-Cの学習においてメモリ管理はひとつの壁であると言えます。そこでその対応策としてAppleはObjective-C 2.0においてガベージコレクションと呼ばれる「メモリ管理をプログラマが一切しなくて良い機能」を搭載しました。しかし残念なことにiPhoneアプリケーション開発用のObjective-Cではまだガベージコレクションが使えません。これはガベージコレクションがCPUのパワーをある程度必要とするからで携帯電話に搭載されているCPUには少し荷が重たいからです。しかし今後iPhone用アプリケーションの開発を考えておられる方は多いと思います。そこで本書では第12章までは基本的にガベージコレクションを使わずにiPhoneアプリケーション開発にも使える従来のメモリ管理方法のリファレンスカウンタ方式を使って学習を進めていきたいと思います。 なおリファレンスカウンタ方式からガベ
iOSアプリ開発のメモリ管理で気をつけること - A Day In The Life
Objective-C での開発にだいぶ慣れてきたのですが、いまだメモリ管理まわりでハマることが多いのでまとめてみました。 メモリを確保してから解放するまでの流れ メモリを確保してから解放するまでの流れは以下の図のようになります(図はアップルのサイトから引用)。 alloc または init すると参照カウントが1になります alloc または init 系メソッドを呼ぶと参照カウントが1になります。 このように書いたのは、クラスの仕様によって alloc メソッドで retainCount が1になるオブジェクトと init 系のメソッドで retainCount が1になるオブジェクトがあるためです。alloc と init はセットで呼ばれることがほとんどなのでこの違いが問題になることはないと思いますが念のため。 int main() { /* allocで参照カウント1 */ NS
iOS 開発で、EXC_BAD_ACCESS とさよならするための６つのルール – Zero4Racer PRO Developer's Blog
2012/3/22 いくつか修正、加筆しました。 追記もご覧下さい：iOS 開発で、EXC_BAD_ACCESS とさよならするための６つのルール [追記] カプセル化について « Zero4Racer PRO Developer’s Blog 対象がiOS4以上の場合は、ARCを使用するのもオススメです。iOS 5 公開記念！ Objective-Cのメモリ管理の革命、 ARC 超入門（サンプルはgitHubに公開） « Zero4Racer PRO Developer’s Blog をご覧下さい。 @Awaresoft さんのこの記事が、ほとんどすべての疑問に答えています。とてもよい記事なので合わせてご覧下さい。プロパティに対応するインスタンス変数の命名規則について – Awaresoft iOS プログラミングでのメモリ管理の基本 iPhone開発で主に使用される言語は、Object
１５秒で訓練なしにできる記憶力を倍増させる方法
繰り返しはあまり役に立たない ものを覚えるのに、今でも頻繁に使われる方法に《繰り返す》というのがある。 これは思ったほど（一般に思われているほど）効果がない。 記憶システムを短期記憶と長期記憶から構成されるものとするレトロな二重貯蔵モデルにおいては，繰り返し唱えたり書きなぐったりして、記憶したい情報を反復することで，短期記憶から情報が失われないようにすると同時にその情報を長期記憶へと転送させるのだと考えられていた。 ところが，情報を単に反復することに時間を費やしても，必ずしもそれが記憶として定着するわけではないことがその後分かってきた。 現在では，こうした《繰り返し》は維持リハーサル maintenance rehearsal(または1次リハーサル primary rehearsal)と呼ばれ，情報を短期記憶に一時的に保持させるに過ぎないと考えられている。 記憶技法はめんどい 情報を長期記
【 iOS 開発 Tips】あなたも気付いていないかもしれないメモリリークの恐怖
こんにちは、共同開発部 iOS アプリ開発担当の図子です。 iOS 開発をしている皆さんはメモリリークのチェックを行っていると思います。どのような方法で確認していますか？おそらく以下のような方法で行っていると思います。 ・Static Analyzer を使う ・Instruments の Leaks テンプレート でも、これだけでは見つからないメモリリークが起こりうることをご存じでしょうか？ addSubview: で何枚もの View を貼っていないか？ 実際にメモリリークと呼べるかどうかは微妙かも知れませんが、開発者の意図しない不要なメモリがドンドン確保される可能性があるのでここではメモリリークと書かせていただきます。 非常に気付きにくいメモリリークとは view に addSubview: する際に起こりやすいのです。 以下のコードを見てください。ある UIViewControll
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer