はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
買い替えを決意せざるを得ない新旧MacBook Air最速ベンチマーク！ - 週刊アスキー
外観は大きく変わっていませんが、キーボードが細かく変更されています。スタバなどで旧MacBook Airユーザーを見かけたら、このファンクション部分を見せびらかせばいいわけです。 早速ですがベンチマークです。今回は旧11インチMacBook Air（Core 2 Duo U9600 1.60GHz）、新11インチMacBook Air（Core i5-2467M 1.60GHz）、新13インチMacBook Air（Core i5-2557M 1.70GHz）で計測を行ないました。 ベンチマークテストに利用したのは『Geekbench』の32ビット版です。 結果は下記のとおり。旧11インチMacBook Airが2277、新11インチMacBook Airが4447、新13インチMacBook Airが5137です。ダブルスコア以上ですよ。びっくりです。「最大2.5倍速くなって……」ってキ
「JavaScriptと性能についての本当の話」をしよう。ダグラス・クロックフォード氏
JSONの発見者でJavScript界の重鎮であるYahoo!のダグラス・クロックフォード（Douglas Crockford）氏。米オライリーが主催するイベント「Velocity 2011」で、セッション「JavaScript & Metaperformance」を行いました。 いまWebブラウザ間でJavaScriptエンジンの性能競争が行われていますが、その影響とこの先の展望について語っています。JavaScriptプログラマなら必見の内容を、公開されたビデオを基に紹介しましょう。 JavaScript & Metaperformance これから、JavaScriptと性能についての本当の話をしよう。 JavaScriptはみなさんご存じかな？ いまや世界で最もポピュラーになったプログラミング言語だ。 JavaScriptは、Javaからシンタックスを、Schemeからファーストク
Cache::Memcached::Fastの高速化
一番簡単に高速化するには シリアライザをData::MesagePackにするとよいかもしれない。 #! /usr/bin/perl use strict; use warnings; use Cache::Memcached::Fast; use Data::MessagePack; use Benchmark qw/timethese/; my $normal = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize_methods => [ \&Storable::freeze, \&Storable::thaw ], }); my $msgpack = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize
Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる
最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？ 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb
Rubyのすゝめ #01 - ベンチマークテストとプロセス管理編 | GREE Engineering
いつもエンジニアブログをチェックしていただいてありがとうございます。グリー株式会社でエンジニアをしている takano32 です。 読者の方々にはプログラマやエンジニアをしている方々も多いと思いますが、みなさんは何か手に馴染んだ道具を持っていますか？ グリーについて言えば「グリーといえば、PHPとMySQL」というイメージをお持ちの方も多いと思いますし、実際にシステムの核心部はPHPとMySQLによって機能しています。PHPとMySQLはグリーに欠かせない道具となっています。 ただ、グリーで働くエンジニアひとりひとりにはやはり個性があり、手に馴染んでいる道具も人それぞれです。 Pythonで社内システム向けのクローラを作成して情報を収集している方、C言語でグリーのシステムに適合するDNSサーバやMySQLプロキシ(g2proxy)を作成している方々などさまざまなエンジニアがグリーでは働いて
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
oinume journal
大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan
標準ファイルハンドルとIO::Fileモジュールのベンチマーク - 半径5メートル
IO::Fileと普通にファイルハンドル使うのとどっちが速いのかなぁと思い、ベンチマークスクリプトを書いて試してみました。 Perlのバージョンは5.8.8です。 #!/usr/bin/perl use strict; use warnings; use IO::File; use Benchmark; my $file = "hoge.txt"; timethese ( 100000, { 'IO::File', '&with_IO_File;', 'FileHandle', '&without_IO_File;', } ); sub with_IO_File { my $fh = IO::File->new($file); push my @lines, $_ while <$fh>; $fh->close; \@lines; } sub without_IO_File { open
InnoDB Plugin 1.0.4 - InnoDB史上極めて重要なリリース
日本時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並
Xslate のベンチマーク。本日時点。 - tokuhirom's blog
Xslate は XS 有効なら圧倒的に高速。PP 版はやはり perl にコンパイルする TMT が圧倒的に高速。とはいえ、PP でも十分な速度はでているので、普段 XS でつかってて、どうしても PP つかわなきゃいけないときの代替として利用する程度なら満足できる。 tokuhirom@gpath% perl benchmark/others.pl [~/dev/Text-Xslate] 木 5 11:55 Perl/5.12.1 x86_64-linux Text::Xslate/0.1054 Text::MicroTemplate/0.15 Template/2.22 Text::ClearSilver/0.10.5.4 HTML::Template::Pro/0.9502 1..5 ok 1 - TT: Template-Toolkit ok 2 - MT: Text::Micr
XML::SimpleとXML::LibXMLのベンチ比較 - (ﾟ∀ﾟ)o彡 sasata299's blog
2008年09月23日18:49 Perl XML::SimpleとXML::LibXMLのベンチ比較 perlで普通にXMLのパースをするには、XML::Simpleを使う方法と、XML::LibXMLを使う方法があります。（もちろんRSSだったらXML::RSSとかもあります）この2つは特徴があって、 XML::Simpleは ・使い方が簡単 ・parseが遅い！！ XML::LibXMLは ・使い方がちょっとわかりずらい ・parseが早い！！ といった感じです（体感）。ただ実際にどのくらいの違いが出てるのか気になって、（簡単ですが）ベンチマークを取ってみました。YouTubeAPIのレスポンスをparseしています。 #!/usr/bin/perl use strict; use warnings; use LWP::Simple; use XML::Simple; use XML
CDBIとDBICのベンチマーク１ - Hatena::Diary::Neko::kak 500 Internal Server Error
DBIx::ClassのMLに流れた情報を自分なりに試す。 ベンチの取り方とかに問題あれば突っ込みお願いします。 テーブル構造はこんなの mysql> desc order_cust; +-------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+----------------+ | id | int(10) | | PRI | NULL | auto_increment | | name | text | | | | | +-------+---------+------+-----+---------+----------------+ 2 rows
サーバやI/O待ちを含むベンチマークを Benchmark::cmpthese で比較してはいけない、という話 - kazuhoのメモ置き場
Benchmark.pm の cmpthese は手軽に速度の比較ができるのでとても便利。でも、そもそも何のパフォーマンスを比較しているのか？ ソースコードを読めばわかるけど、 perl プロセスのCPU使用時間 あるいは、上記＋子プロセスのCPU使用時間 を測定している。換言すると、プロセス間通信のオーバーヘッドやサーバ側での処理時間はベンチマーク結果に反映されない。つまり、サーバのベンチマーク（あるいはプロセス間通信やI/O待ちを含むベンチマーク）を比較したい場合には、cmpthese を使うべきではない。 ＃サーバと通信するクライアントモジュールのベンチマークがほしい、といった場合はOK どうしても Benchmark.pm を使いたいなら、 use Benchmark qw(:hireswallclock); my $r = timethese(...); for my $v (v
Opera News
Opera for iOS Introducing Opera One for iOS: a fresh take on mobile browsing August 14th, 2024 We're excited to announce the launch of Opera One for iOS, our redesigned, AI-powered browser for iPhone. Opera requests that the EU General Court secure the DMA’s promise of free browser choice... July 12th, 2024 Opera is appealing the EU Commission’s decision not to designate Microsoft Edge as a gateke
Benchmark
Perl の処理速度を比較するために使用するモジュールです。複数の処理の処理速度を求めて比較できます。 URL デコードの二つを例にします。「Perlの小部屋」という文字列をデコードしています。 #! /usr/bin/perl use Benchmark; $count = 100000; $value = "Perl%E3%81%AE%E5%B0%8F%E9%83%A8%E5%B1%8B"; timethese($count, {'TEST1' => '&test1;', 'TEST2' => '&test2;', }); sub test1 { $str = $value; $str =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/pack("H2", $1 )/eg; } sub test2 { $str = $value; $str =~ s/%([0-9A-Fa-
HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta
MongoDBのパフォーマンスをBerkeley DB, H2, MySQLと比較 - kaisehのブログ
スキーマレスのドキュメント指向データベース、MongoDBがとても面白そうだったので、Javaから使用した場合のパフォーマンスを計測してみました。 MongoDBはCouchDBに似たデータベースで、任意のオブジェクトを保存できますが、MVCCやREST APIを採用しないことで高パフォーマンスを追求しているようです。インデックスやレプリケーションのサポートも充実しています。 RDBMSをKey-Value Storageとして使う場合のパフォーマンス計測（H2, MySQL編） - kaisehのブログ 前に上記のエントリーでBerkeley DB, H2, MySQLのパフォーマンスを比較したことがあるのですが、そのときと同等の条件になるようにして計測しました。 具体的な計測方法は以下の通りです。 Mac OS 10.5.7, 2GHz Intel Core 2 Duo, 4GB Me
qmailとPostfixのパフォーマンス比較 - matabii's blog
今の環境がqmailで、今後どちらを使うか？と言われるとPostfixなのですが、心置きなく移行するために速度の比較を行ってみました。ベンチを取るならPostfixにsmtp-sourceというソフトがついているのですが、実際に送信した時のパフォーマンスが見たかったので、実験サーバ計4台とDNSを立ち上げて普通の環境に近い形で比較しました。 実験環境（送信サーバ） OS：CentOS5.2（素カーネル2.6.18） CPU：Xeon X3220 2.4GHz core*4 メモリー：4GB qmail-1.03 /var/qmail/control/concurrencyremote /var/qmail/control/concurrencylocal 上二つを120で作成し、配送プロセス数の上限を120にしました。 postfix-2.3.3-2 default_process_lim
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://hibinokoto.jp/archives/2007/10/post-217.html