このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ＆ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ（t32k.me）が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
Java 5から列挙型(enum)が導入されたのに合わせて、列挙型の値をキーとするEnumMapというクラスが提供されているのを知り、またメモリ効率がよいという記述をどこかで見たので、ちょっと実験。 まず列挙型。 enum A { A_1, A_2, A_3; } 次にテスト用のクラス。EnumMapを一つ作り、そのコピーを指定した個数だけ生成してリストに格納する。 import java.util.EnumMap; import java.util.List; import java.util.Map; public class EnumMapTester { public void test(int n, List<Map<A, String>> list) { Map<A, String> m1 = new EnumMap<A, String>(A.class); for (A a
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
例外に掛かる処理コストについてint.Parseとint.TryParseを使って比較調査を行ってみました。 入力された文字が数字か否かを判断する方法として、数値ではない場合に例外を発生させるint.Parseがあります。 private bool IsNumericByException(string test) { try { int.Parse(test); } catch (FormatException ex) { return false; } return true; } もうひとつ別のバージョンとして、数値ではない場合にFalseを返すint.TryParseがあります。 private bool IsNumericByTryParse(string test) { int a; return int.TryParse(test, out a); } この２つの処理をそれぞ
ちょっとしたログ解析(細々としたのを結合して全部で10万件ぐらい)に書き捨てコンソールアプリケーションを使って行っていたのですが(データ解析はC#でLinqでコリっと書くのが楽だと思うんです、出力するまでもなく色々な条件を書いておいてデバッガで確認とか出来るし)、実行の度に毎回読んでパースして整形して、などの初期化に時間がかかってどうにも宜しくない。そこで、データ丸ごとシリアライズしてしまえばいいんじゃね？と思い至り、とりあえずそれならバイナリが速いだろうとBinaryFormatterを使ってみたら異常に時間がかかってあらあら……。 というしょうもない用途から始まっているので状況としては非現実的な感じではありますが、標準/非標準問わず.NET上で実装されている各シリアライザで、割と巨大なオブジェクトをシリアライズ/デシリアライズした時間を計測しました。そんなヘンテコな状況のパフォーマンス
概要 .NET Framework のバージョンが上がるたびに色々と追加され、 今や、動的コード生成にもさまざまなやり方が。 ということで、並べて比較してみたいと思います。 「動的 ＝ リフレクション ＝ むちゃくちゃ遅い」というイメージをもたれる方も多いと思いますが、 実際のところ、1度生成したコードをキャッシュしておくなどの工夫をすれば、意外と許容範囲なパフォーマンスが得られます。 （GUI の描画部分やネットワーク通信部分の遅延と比べれば、演算部分の数倍程度の差は取るに足らない場合が多く、 過剰に気にする必要はありません（もちろん、状況次第）。） 比較コード含めたソースコード一式： DynamicPerformance.zip ポイント 毎回リフレクションを呼び出すのはやっぱりかなり（2～3桁）遅い。 キャッシュ機構を使えば、静的なコードの数倍程度までは速くできる。 C# 4.0 の
![[雑記] 動的コード生成のパフォーマンス(C# によるプログラミング入門)](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d1b2b57fc676d21e7f59f354364abeac0ea062e/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fufcpp.net%2Fimages%2Flogo_4.jpg)
2009-01-12追記 タイトル修正しました。 2009-01-14追記 String.indexOf と RegExp.test のスコアが逆に書かれてていたのを修正しました。 String.match ばかりで、RegExp.exec を使ったことがありませんでした。 ちょっと気になったので色々とベンチマークを取ってみました。 TEST TIMES IE6 Fx3.0 Fx3.1 (JIT) Safari3 Chrome1 (JIT) A. match(/\s*/) vs match(/ */) "aaaaaaaaaaaa".match(/\s*aa\s*/) 1000000 7203 1714 327 2375 2128 "aaaaaaaaaaaa".match(/ *aa */) 1000000 7156 1638 297 2328 2148 B. RegExp.exec vs
この記事は abicky.net の JavaScriptでマッチ文字列全置換はどうするのがいい？ に移行しました
DOMユーザーの方は、このようなことが出来たら良いと思ったことはありませんか? NodeListのクローンを作成する NodeListをそのままappendChildのパラメータにする もちろんこのようなことは出来ません。NodeListのitem一つ一つのクローンを作成し、一つ一つをappendChildしなければならないのです。しかし、DocumentFragmentを利用することによって、このような感覚の操作をすることが可能になります。 Foot note この記事のURI参照 http://members.jcom.home.ne.jp/jintrick/Personal/documentFragment.html#seeds ここに、文書A、文書B、文書C があったとします。 文書A <rootA> <item /> <item /> <item /> <
こんちは、中村です。 先日マピオンラボよりリリースしたiPad用地図「マピオンタッチ デラックス」のコアとなるフリースクロール地図ライブラリの開発を担当させて頂きました。せっかくなのでターゲットブラウザをMobileSafariに設定し、比較的スペックがプアなiPhone3Gや3GSでも十分な速度で動作するようJavaScript部分の高速化をアレコレ調べてみたのでまとめてみます。一番低スペックなiPhone3Gで実際にどの程度早くなるかをタイマーで計測してみましたってのが本エントリーのミソです。 JavaScriptパフォーマンスチェック - Googleドキュメント 1. new Object より {}（Objectリテラル） オブジェクトを１万個生成するならばリテラルで記述することで約26ms高速化！ loop=10000; for(var i=0;i<loop;i++){}; /
JavaScriptでFirefoxがconst(定数宣言)をサポートしていることをフと思い出しました。で、定数宣言って速度向上とかにつながるのかな？思ってついカッとなってベンチマークとるコードをかいてみました。こんな感じ。 <html> <head><title>const test</title></head> <body> <script> window.load = monitor(); function monitor(){ var A = "TestA"; const B = "TestB"; var Klass = { C : "TestC" }; // 1st test var start = new Date(); for(var i=0; i<10000000; i++){ var b = A; } var end = new Date(); console.log("
8 ヶ月前に setInterval 書き換えのネタで作ったやつ id:amachang:20060104:1136344836 id:amachang:20060114:1137243389 ふと ちょっと設計変えたらすごく速くなる気がして、作り替えてみた。 でも、作ってみたら clearInterval がちょっとだけ速くなったけど、正直そこまで変わらなかった。 でも、設計はきれいになったと思うので公開します。 ダウンロード http://sample.ecmascript.jp/setInterval/setInterval03.js 以前のもファイル化した 最初の失敗作(utf-8だから適当にエンコードして使ってください) 次に作ったやつ、実績はこっちのがある(utf-8だから適当にエンコードして使ってください) 使いかた すべてのスクリプトより前に読み込む <script src
前回(id:amachang:20060104)の改良版です。前回のでやっていたら、queueを走査する時間がかかりすぎるようになって結局崩壊してしまったので、さらに改良しました。ただし、今回のは時間が多少ずれる場合があります。なので、ストップウォッチなどのプログラムを作る場合は使わないでください。 主な改良点としては .(ドット) 減らす。 文字列リテラルをループ中に記述しない。 ループ。ループのネストを減らす。 new を減らす。 関数コールを減らす。 より早い演算を使う。(+1 を ++ にするとか。他にもいっぱい) これで、めっちゃ早くなりました。やヴぁいです。 ミニマム版 var _SIi=10,_SIM='第一引数が不正です。',_SIl=0,_SIc=0,_SIS ='string',_SIF='function',_SIf=window.setInterval,_SIp=[
以下のスクリプトを他のすべてのスクリプトよりも前に読み込む。 var nativeSetInterval = window.setInterval; _setInterval = {}; window.setInterval = function(process, delay) { var entry; if(typeof process == 'string') { entry = new _setInterval.Entry(function(){eval(process);}, delay); } else if(typeof process == 'function') { entry = new _setInterval.Entry(process, delay); } else { throw Error('第一引数が不正です。'); } var id = _setInterv
GCを適切に行わせるためのヒープサイズの設定 JVMにGCを適切に行わせるにはヒープサイズを適切に設定（New領域サイズ、Old領域サイズ、領域サイズのバランスなど）する必要があります。当然、適切なヒープサイズはアプリケーションに依存します。一般にヒープサイズが小さいとGCが頻発してアプリケーションのパフォーマンスが低下します。さらに、ヒープサイズが必要量を下回る場合はOutOfMemoryErrorが発生してアプリケーションが停止してしまいます。一方、ヒープサイズが大きいと、GCの起動回数は減りますが、GC1回当たりの処理時間、すなわちアプリケーション停止状態が長くなり、アプリケーションの応答時間に問題が出る場合もあります。システムの物理メモリのフリー領域が不足するまでヒープサイズを大きくすると、物理メモリからスワップ領域へのページングが起こってしまい、かなりのパフォーマンスが劣化する可
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
LANケーブルを買いに家電量販店に行くと、フラット・極細・より線・カテゴリー5・5e・6・6a・7などいろいろな種類のものがそろっていますが、LANケーブルを選ぶ際に重要視するポイントはカテゴリーで、5・5e・6・6a・7に分けられ、5・5e・6・6a・7の順に通信速度・伝送帯域などが高性能になり高価になります。また、同じカテゴリーでもLANケーブルの形状が通常より平らになったフラットケーブルや細くなっているものがあるので、通信速度に違いがあるのか実際に計測して確かめることにしました。 ◆集めたLANケーブル 会社ごと・製品ごとの違いを確かめるため、家庭でも使えて売れ筋の長さが5メートルで、なおかつカテゴリー5e・6・6a・7が全部そろっていること、という条件で探していった結果、エレコム・サンワサプライ・バッファロー・ミヨシの4社のLANケーブル、合計38種類を計測することに決定。 実際に
みんな知っていることかもしれないけれど・・・。 array_map 関数って便利だなー、是非活用しよう！と思ったんですがもしかしたら速度に問題ないだろうか？と思って調べてみました。 ネットで調べたところでは、 http://www.stackasterisk.jp/tech/php/searchAction.do?cid=27 というのがあって array_map 関数のほうが速いと書いてありました。 でも簡単に作った比較のスクリプトでは array_map の方が遅くて、for文よりも foreach文の方がはやかったのです。 どうやら、 for($i=0; $i<count($array); $i++ ) { ここの配列の数を毎回取得しているのが原因なのと $i++ より ++$i の方がはやいらしい。なぜかは今は知りませんｗ これを直してテストをしました。 また繰り返しも加えたのと
http://www.slideshare.net/fabpot/php-53-in-practice/48 のスライド48枚目より Fabien さんの1年前の調査に触発されて、自分の Macbook Pro で調べてみました。PHP のバージョンは trunk (201109170830) で debug モードが有効です。 処理速度に関しては Fabien さんとほぼ同じ結果になりましたが、memory_get_peak_usage 関数を使って割り当てられたメモリの最大値の変化量を調べると foreach を100とすると array_map は約160で、メモリを余計に使っていました。 array_map とクロージャを組み合わせることで、コンパクトな表記になったり、計算の際に必要な一時的な配列のスコープを絞り、foreach のように配列のポインタを操作しなくて済みますが、パフ
Scythe（サイズ） KABUTOクーラー SCKBT-1000 Crucial（クルーシャル） RealSSD C300 CTFDDAC128MAG-1G1 128GB SSD Western Digital WD1002FAEX 1TB HDD LG WH10LS30 Serial-ATA接続 内蔵Blu-rayドライブ Windows 7 Home Premium 64bit SP1 DSP版 ケース、電源、グラフィックボードetc…は既存のものを流用しました。おすすめパーツ今ならP67とH67の特徴を併せ持つZ68マザーボードと Crucial m4 SSD CT128M4SSD2 128GBの組み合わせがいいかもしれません。 Core i7 2600K + Z68マザーボード Crucial m4 SSD CT128M4SSD2 Windows 7のインストールSSDをSATA
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
