IntelliJ IDEAの動作が遅い時の対策 - a tomato
普段は、InteliJ IDEAを使って開発しているのですが、メモリの初期設定が以下のようにかなり少ないです。 初期状態で開発を行うと、アプリケーションの規模によっては内部indexの作成に時間がかかりかなりストレスが溜まります。 開発のストレスを少しでも軽減するために、設定の変更で利用するリソースを適切に調整して対処を行います。 -Xms128m -Xmx2048m -XX:ReservedCodeCacheSize=240m -XX:+UseCompressedOops そこで、端末のメモリ状況に合わせて、ヒープサイズを増やします。 Intelijを起動して上部のHelpメニューないから下記の項目を開きます。 すると以下のようなファイルがIntelij内で開かれます。 ここの数値を今回は、以下のように変更します。 -Xms2G -Xmx4G -XX:+UseG1GC -XX:-UseP
ゼロから学ぶ C++
ホーム 1. C++ を始める 2. 基本構文 3. コンテナ 4. ファイル分割とスコープ 5. ストリーム操作 6. メモリの管理 7. クラス 8. キャスト 9. テンプレート 10. エラー処理 11. ビルドとライブラリ 12. メモリレイアウト 単体テスト デバッグ ビルド自動化 付録 このサイトは C++ について説明した学習サイトです。 本書を通じて C++ の開発環境や構文・単体テストの書き方などが 一通り学べるようになっています。 対象¶ C++ を初めて学ぶ人 プログラム言語を 1 つ以上経験したことのある人 関数やクラス・オブジェクト指向に対する知識をある程度前提にします。 C++ の特徴¶ C++ は ビャーネ・ストロヴストルップ により開発されたプログラミング言語です。 C++ には主に次のような特徴があります。 高パフォーマンス メモリ使用量が少ない 柔軟性
【Unity】Unityでメモリリークを分析するための5つの方法 - LIGHT11
Unityでメモリリークを分析するための方法をまとめました。 Profilerでメモリが増え続けていることを確認する Profilerでネイティブメモリに乗っているオブジェクト数をチェックする ProfilerのMemoryをDetailedモードにして参照関係をチェックする Memory Profilerでメモリをキャプチャして明らかに数の多いオブジェクトを探す Memory ProfilerのDiff機能でフレーム間の差分を取る 関連 Unity2018.4.0f1 Profilerでメモリが増え続けていることを確認する まずは何はともあれメモリがリークしていることをProfilerできちんと確認します。 Profilerの基本的な使い方は次の記事にまとめていますので必要に応じて参照してください。 light11.hatenadiary.com メモリのProfilerはネイティブメモ
Sharplab のMemoryGraph を使ってメモリの状態を確認する - tech.guitarrapc.cóm
以前 TryRoslyn と言われてたサービスですが、今は Sharplab という名になっています。 このサービスを使うと、コードがILやネイティブコードにどのようにコンパイルされるか確認したり、実行したりオブジェクトのメモリ状態を確認できます。 例えば次の図は、構造体の文字列がどのようなメモリ状態なのかを示したものです。 Sharplab を使って、コードだけでなくメモリ状態を可視化することで理解を深めるきっかけにできるか見てみましょう。 目次 目次 TL;DR; Sharplabの基本 いつ使うのか コードの共有 言語選択 表示の切り替え(Decompile) 言語ごとのデコンパイル結果の比較 Other Run C# のメモリ状態を確認する Boxing を可視化する 構造体における文字列の参照状態を確認する クラスにおける参照状態を確認する TL;DR; Shaplab を使って
「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama
自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの
インテル、ついに不揮発性のメインメモリ「Intel persistent memory」発表、実稼働デモ公開。2018年に新型Xeon「Cascade Lake」とともに登場予定
Intel persistent memoryはデータの保持に電力を必要としない、不揮発性メモリの一種だ。データをメモリからストレージに保存する必要がなくなるなど、コンピュータのアーキテクチャを一変させる可能性を持つ。 現代のコンピュータは基本的にメインメモリとしてDRAMを利用しています。DRAMはアクセスが高速な一方、容量あたりの単価は高く、それゆえ大量にコンピュータに搭載することが難しく、またデータを保持し続けるのに電力を必要とします。 このDRAMの能力と性質を補完するため、一般に現代のコンピュータには二次記憶装置として大容量で安価かつ電力がなくてもデータを保持し続けられるハードディスクドライブなどのストレージを備えています。 こうした現代のコンピュータの構造を一変させようとインテルが5月16日に発表したのが、大容量かつ低価格、しかもデータの保持に電力を必要としない、同社とマイクロ
UnityのGCはどんな実装になっているのか
こんにちは。Aiming エンジニアの久保田です。 僕の携わっているプロジェクトでは、近頃、Unity製クライアントのパフォーマンスの調査や改善を行っている最中です。 プロファイラを眺めていると、僕達が書くアプリケーションレイヤのコードが目立って遅い、ということは珍しいのですが、代わりにC#世界のスパイクとしてよく顔を出すのが、GC実行時間です。 C#は、タイプセーフでありながら人間にやさしく、getter/setter、async/await、Rx、ロケットなラムダ式、他他他…最新型の言語への影響も多大な、ファッション的にも◎な言語です。しかし、闇雲に全ての機能をタダで……というわけにはいかず、ことパフォーマンス面においては、GCというなかなか高い代償を支払うことになりかねないわけですね。 結論としては、UnityのGCは、皆が期待していたほど高性能ではなく、現状では僕達が書くC#が発生
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方 - Qiita
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
GPU本来の性能を引き出すWebGL頂点データ作成法 - Qiita
この記事はWebGL Advent Calendar 2015の９日目の記事です。 ご注意 本記事は2015年当時に書いた記事なのですが、GPUがGeForce 8x00シリーズ以降、SIMDからSIMTという並列実行形式に切り替わった頃から状況が大きく変わりました。 以前は本記事でも紹介するインターリーブ形式の頂点データの方が高速だったのですが、現在のGPUでは多くの環境で非インターリーブの方が高速とされています。 AMD GPUにおいても、GCNアーキテクチャ（PS4以降の世代）から（それまでのVLIWから）SIMTに切り替わり、非インターリーブを推奨されているようです。 WebGLは基本的にネイティブ3D APIへのマッピングに過ぎないため、この傾向はおそらくWebGLでも同様と考えられます。 とはいえ、インターリーブ(AoS)や非インターリーブ(SoA)はCGをやる上でいずれ避けて
VMR9とNV12で嵌る（その３） - Exhaust gas
かなり間が空いてしまったが、前回の書き込みについて、「何が言いたいのか、よく分からない」と言うメールを受け取ったので、纏めを少し書いておこうと思う。 そもそもの発端は、DXVA1のデインタレース機能の評価を行おうと思って、以下のようなDirectShowフィルタ（以下、ソースフィルタ）を用意すれば良いと考えたことだった。 VMR9に直接接続する。 VMR9に、NV12サーフェス（バッファ）を用意させる。（アロケータはVMR9の物を使う。） NV12サーフェスに、インタレースの画像データを書き込んで、VMR9に表示させる。 ソースフィルタ側で、FPSやフィールドの設定を行えるようにする。 このようなソースフィルタが用意できれば、DXVA1で定義された複数のデインタレースモードで、どのような補間が行われて、出力画像の何が違うのか、確認できるだろうという考えだ。 そういう訳で、「そんなに難しくな
Instruments の Leaks の見方（Live Bytes や Living の意味） - その後のその後
このLive BytesやらLivingやら、タイトルから大体推測できるものの、ちゃんとした定義をしりたかったのですが、ヘルプ内を探しても見当たらず、iOS開発関係の本を見てもどの値が何とまでは書いてくれていませんでした。たまたまググったら出てきたので、下記にまとめておきます。 Live Bytes The Live Bytes column indicates how many of this type of object have been allocated and still are around in memory. 該当するタイプのオブジェクトの現在のメモリ使用量 # Living # Living column tells you how many objects of this type are still around in memory. 該当するタイプのオブジェクトが
Cocoaの日々: CoreData - 大量データを扱う場合のメモリ利用量を減らす
データ件数は、Customerが 500件、Karteが6,000件（Customer１件につきKarte 12件）となっていて、それぞれを１つの CSVファイルへ書き出す。 処理は次のような感じになる。 NSMangedObjectContext* moc = [取得]; NSArray* customers = [moc Customer全件取得]; for (NSManagedObject* customer in customers) { NSArray* kartes = [moc Karte取得・条件：customer]; for (NSManagedObject* karte in kartes) { [CSV１行書き出し]; } }メモリのフットプリント（利用状況）はこんな感じ。 Customer, Karte を１件づつ読み込む度にメモリが消費され、フットプリントが増大し
その12 イテレート中のSTLのlistから要素を安全に削除する方法
ホーム < ゲームつくろー！ < Programming TIPs編 その12 イテレート中のSTLのlistから要素を安全に削除する方法 STLのコンテナは「イテレータ」によって要素を取り出します。この時良くあるのが「ある要素をチェックして、必要が無くなった場合はリストから削除する」という作業です。例えば描画オブジェクトのリストからもういらなくなったオブジェクトを除く時などこの作業が必要になります。 イテレート中のリストから要素を除く場合、ちょっと注意しないと思わぬバグが誘発します。この章ではイテレート中のリストから要素を除く方法をまとめます。まさにTIPsです(^-^;。 ① まともにやるとあっさりバグ 例として、int型のリストに0～9までの要素がこの順番で登録されているとしましょう。このリストをイテレートして「5」を取り除きたいとして、次のようなコードを書きました：
【JavaScript】メモリの浪費を避けるコーディング | ヘッドウォータースのブログ TechNote
こんにちは。良昌です。 Facebook、GithubなどのJSON形式でユーザ情報を返却するAPIや、PhoneGap、Monacaなどのスマートフォンのマルチプラットフォームを提供するライブラリ、IDEが開発ツールとして定着してきたことにより、JavaScriptを利用する機会が増えたのではないでしょうか。 今回は、JavaScriptコンテナがWebブラウザの場合に、動的に確保されるメモリ領域の浪費を避ける方法について書きたいと思います。 JavaScriptにおけるメモリの浪費を避けるコーディング JavaScriptにおけるメモリの浪費を避けるコーディングをするためには、GC(ガベージコレクション)、クロージャについての知識が必要です。まずは、この2つの機能について説明していきます。 ■GC(ガベージコレクション) GCとはプログラムが動的に確保したメモリ領域の内、不要になった領
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AviUtlはいかにして4GBのメモリの壁を超えたのか - Qiita
CoreFoundation入門 メモリ管理
「Google Chrome」のタブを“サスペンド”して使用メモリを削減「The Great Suspender」NOT SUPPORTED