はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
length プロパティのパフォーマンス: Days on the Moon
「for 文 2.0」(IT戦記) では length プロパティの評価をループの外に出すことにより高速化を図っています。DOM の NodeList オブジェクト (document.getElementsByTagName() などで取得) や HTMLCollection オブジェクト (document.forms などで取得) の length プロパティは「生きている」(オブジェクト取得後の操作が反映される) 、すなわち誤解を恐れずいえば評価のたびに数えなおす必要があるので遅いというのも納得ですが、JavaScript のネイティブオブジェクトである配列の length プロパティはどうなのでしょうか。実際に調べてみました。 以下は 10000 個の span 要素に対する NodeList オブジェクトと配列の length プロパティのパフォーマンスを調べた結果です。数値は
YappoLogs: TokyoCabinetがPerlのHASHより遅いわけがない！
TokyoCabinetがPerlのHASHより遅いわけがない！ こんにちわ！金曜日担当・Shibuya内フェアリーことYappoです。 mixi Engineers’ Blog » PerlとRubyで省メモリなハッシュを使おうにて 100万件のレコードを格納した場合のメモリ使用量と処理時間を測ってみましょう。Perl（5.8.8）でテストコードを動かしたところ、以下の改善が確認できました。標準のハッシュに比べて、メモリ使用量がTCのオンメモリハッシュだと約61%、TCのオンメモリツリーだと約37%になることがわかります。処理時間に関しては157%ほどになっていますが、まあ許容範囲ですよね。といった事が書かれており、その文面の上の解説で、tieしたので、tieしてるからおせーんじゃねーの？とテストコードも見ないで呟いてたらmikioさんからtie使わないでやってるよ！とつっこんでいただき
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
文字列繰り返しベンチマーク take 3 - moriyoshiの日記
これの続き。 なんかかなりjitterがあるみたいでおかしな結果になってるんだけど、アルゴリズムごとの特徴は出てるので。 - Chrome FF3.0.5 FF3.1b2 IE6.0 IE8.0b2 Opera Safari WebKit/r40352 concat_op 32 203 150 747586 453 156 51.5 32 join 36 478 596.5 562.5 234.5 445.5 87.5 38 hybrid 5 99.5 108.5 156 195.5 195.5 23.5 18 newbulk 0 38 52.5 47 15.5 54.5 1.5 2 ちなみにnewbulkのコードは var newbulk = function(s, n) { var s, r = ''; while (n > 0) { if (n & 1) r += s; s += s
アルゴリズム - 同じ文字列のn回繰り返しをlog n回で作る方法 : 404 Blog Not Found
2009年01月31日01:00 カテゴリLightweight LanguagesMath アルゴリズム - 同じ文字列のn回繰り返しをlog n回で作る方法 これなのですが.... 同じ文字列のn回繰り返しを作る最速の方法を探求してみた - muddy brown thang ちょっとした事情により、ある文字列のn回繰り返しを作る関数 (PHPでいうところのarray_repeat(), Perlで言うところの「"..." x n」、RubyやPythonで言うところの「"..." * n」) を高速に実装しなければならない状況に遭遇したのでベンチマークをとってみたところ、その結果がとても新鮮で驚いたので、これを共有しつつもダメ出ししてもらえないかなーと思って晒してみることに。 なぜかもっとシンプルな奴がなかったので。 以下、比較。初期値はIEにあわせてあります。Firefox/Saf
DBにパスワードを保存する際に、どのハッシュを選ぶか - Yappo::タワシ
というのを速度とハッシュ後のサイズだけみてみた。 安い速いだけが選定基準にはならないって事を注意書きしとく。 # いろいろ追加した md5 : 16 sha1 : 20 sha224 : 28 sha256 : 32 sha384 : 48 sha512 : 64 hmac_sha1 : 20 hmac_sha512: 64 Rate hmac_sha512 sha512 sha384 hmac_sha1 sha224 sha256 sha1 ds_sha1 md5 hmac_sha512 36364/s -- -68% -70% -82% -89% -90% -92% -96% -97% sha512 114943/s 216% -- -4% -42% -67% -67% -74% -87% -90% sha384 119760/s 229% 4% -- -39% -65% -66% -
Perl スクリプトで遅い場所を特定する方法 - Devel::Profiler / Devel::NYTProf
今仕事で書いてる Sledge アプリがあるのですが、先日負荷テストを行った結果びっくりすることに現行アプリの１０倍遅いことが判明してしまいました・・・orz Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 さて、プロファイラを使うとプログラム実行時の各種情報を収集し、性能解析を行うことが可能です。プロファイラについてもう少し詳しくしるには 性能解析 - Wikipedia あたりを読むと良いでしょう。 プロファイラ（英: Profiler）は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの
Perl 最速伝説k - Yokohama.pm Teck Talk #1
と言う事で、連結する変数が多くなると途中から join が最速になる。"$a$b$c" のような形式は最適化されて $a . $b . $c となるようだがやはり数に関わらず最も遅いので使わない。 続・スカラーの文字連結 http://www.ibm.com/developerworks/jp/linux/library/l-optperl/ より 他にも色々拡張してみた。 #!/usr/bin/perl use strict; use warnings; use Benchmark qw(:all); my $limit = 100; my $sets = { concat1 => sub { my $string = 'abcdefghijklmnopqrstuvwxyz'; my $concat = ''; for (1..$limit) { $concat .= $string;
+=とjoinの速度比較 - 素人がプログラミングを勉強していたブログ
JavaScript文字列処理は"+="が十分高速、Safariもベター | エンタープライズ | マイナビニュースにびっくりしたので、最近のFirefox(Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/2008080108 Minefield/3.1a2pre)でベンチマークを行なった。+=は確かに早い。 console.time("String.concat"); var s = ""; for (var i = 0;i < 10000;i++) s += String.concat( "aaa", "bbb", "cccc", "dddd" ); console.timeEnd("String.concat"); console.time("Array.prototype.joi
perl - 勝手に添削 - 神経質（A型）なPerlハッカーあるある : 404 Blog Not Found
2008年03月14日12:45 カテゴリLightweight LanguagesTips perl - 勝手に添削 - 神経質（A型）なPerlハッカーあるある あきまへんなあ。 神経質（A型）なPerlハッカーあるある - D-6 [相変わらず根無し] if ($foo eq 'XXX' || $foo eq 'YYY')を if ($foo =~ /^(XXX|YYY)$/) に書き直したくなる 速度的にも、正規表現よりも eq || eq の方がいい場合が多いのよ。 #!/usr/local/bin/perl use strict; use warnings; use Benchmark qw/timethese cmpthese/; my @mongers = qw/dankogai dconway dmaki drolsky/; my %who = map { $_ => 1
たった3行加えるだけで、ページの読み込み時間を劇的に改善させる『class.compressor.php』 - IDEA*IDEA ～ 百式管理人のライフハックブログ ～
ドットインストール代表のライフハックブログ
Cache::Memcached::Fastを試す : blog.nomadscafe.jp
Cache::Memcached::Fastを試す Perlの新しいmemcachedクライアント「Cache::Memcached::Fast」がでていたので試してみた 結論から言うと、これは使えそう。 まず、C::M::Fastはmemcached-1.2.4でサポートされた、append, prepend, cas, gets, gets_multiをサポートする唯一のPerlクライアントです。また、常に問題となるCache分散にKetama consistent hashing algorithmをサポートしているためCacheの組み替えを最小限にしてCacheサーバの追加が行えます。 手元のベンチマークでは50%〜80%、処理によりますが300%以上高速化されてます インストールは普通にCPANから行えます。ただし、memached-.1.2.4が動いていないとmake test
JavaScriptライブラリのパフォーマンス、最速はコレだ! | エンタープライズ | マイコミジャーナル
The PBwiki engineering teamのメンバーがWebブラウザとJavaScriptライブラリのパフォーマンスを調査するために興味深いパフォーマンステストサイトを公開している。Javascript Library Performance Test Roundupにアクセスして"Run (West Coast)"かまたは"Run (East Coast)"をクリックしてみてほしい。使っているWebブラウザにおいてDojo 1.0.1、jQuery 1.2.1、Prototype 1.6.0、YUI 2.4.0、Protoculous 1.0.2の読み込み時間がどうなるかを調査してくれる。 しかも読み込み方法は通常のJavaScriptソースコード、キャッシュされたものとそうでないもの、Gzipで圧縮されたものとそうでないもの、YUI Compressorで最小化されたものと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WordPress › インストール
JSON module 処理速度検証 (JSON::Syck VS JSON::XS) - Perl