エンコーディング変換の高速化 - odz buffer
ref:404 Blog Not Found:perl tips - Encodeを速く使う方法 当然の話だけど、対象の文字列が長くなると、Encode::encode も、$e->encode も大差ない。 ちょっといじって試してみる。 use strict; use warnings; use Benchmark qw/cmpthese timethese/; use utf8; use Encode; use Jcode; use Unicode::Japanese; use Smart::Comments; my $str = join '', ( 'a' .. 'z', ( map { chr } ord('ぁ') .. ord('ん') ) ); $str = $str x shift if @ARGV; my $bytes = encode_utf8($str); my $u
404 Blog Not Found:perl tips - Encodeを速く使う方法
2007年04月23日01:30 カテゴリLightweight LanguagesTips perl tips - Encodeを速く使う方法 はっきり言ってこれはフェアではない。 みかログ: ErlangとPerlの速度比較 Perl側は，Encodeが遅い． Encode::from_toがinplaceでコンバートしてしまうために，直前に文字列コピーがあるのも影響しているのかも なぜなら、Encode::from_to()は速度ではなく、安全性に最適化しているから。 そもそもはじめからUTF-8、それもutf8フラグがたっている文字列にfrom_toを使うのはばかげている。 for(my $i = 0; $i < 0xffff; $i++) { my $str2 = $str; Encode::from_to($str2, "UTF-8", "Shift_JIS"); } は単に
わかりやすい Perl チューニングの話
ミケネコ研究所 / プログラミング研究室 / Perl チューニング わかりやすい Perl チューニングの話 Perl の内部構造とパフォーマンス・チューニング Last modified: 2001/09/24 はじめに 第 1 回 メモリ割り当て 第 2 回 値のコピー つづくの？ はじめに この文書は、Perl の内部構造を知り適切なプログラム設計およびパフォーマンス・チューニングを行えるようになることを目的としています。読者は「プログラミング Perl」（通称青らくだ本）の所持を前提としています。 らくだ本「８．３ 効率の問題」の項は興味深く、時間効率・空間効率に関するいくつかのヒントが載っていますので、是非読んでみてください。しかしそこから Perl の内部挙動を読み取ることは至難の業です。この連載では、もう少し Perl の内部に立ち入ってみたいと思います。 第 1 回 メモ
Text::MeCabの処理時間 - ぞえ の戯れ言
Text::MeCabでのわかち書き処理が遅い件について、記録を取っていなかったので再度処理時間を計り直しました。 用意した文章は次のものをUTF-8に変換したものです。 実際に来た迷惑メール(1767バイト) 青空文庫より『瓶詰地獄』（夢野 久作著）(25496バイト) 青空文庫より『黒死館殺人事件』（小栗 虫太郎著）(1039324バイト) MeCab $ time mecab -Owakati < ~/spam-utf8.txt > /dev/null real 0m0.009s user 0m0.004s sys 0m0.004s $ time mecab -Owakati < ~/binzume_jigoku.txt > /dev/null real 0m0.045s user 0m0.032s sys 0m0.012s $ time mecab -Owakati < ~/kok
単純データのシリアライズ速度比較 - Tociyuki::Diary
最近の CPAN モジュールで Storable を当たり前のように使っているのをみかけるのですが、入れ子になっていないフラットなハッシュ程度の単純なデータをシリアライズするには重いのではないかとベンチマークをとってみました。ついでに、以前から比較してみたかった pack/unpack の固定長と可変長の比較もやってみました。ベンチマークをとるのは、ハッシュのシリアライズでありがちな要素数の少ない文字列リストと、配列のシリアライズでありがちな要素数が多い整数リストの 2 つにしました。 結論 要素数が少ないハッシュのシリアライズには split/join が速いようです。 要素数が多い整数のリストのシリアライズには整数 unpack/pack が速いようです。 可変長文字列 unpack/pack は split/join よりも遅いようです。 単純なデータ構造では Storable のメ
[を] Perlのプロファイラ - Devel::DProf
Perlのプロファイラ - Devel::DProf 2006-11-06-3 [Programming] Devel::DProf http://metatoys.org/propella/tips/Devel_DProf.html DProfの話は、「プログラミングPerl 第3版 VOLUME 1」の 第20章「Perlデバッガ」に載っています。 デバッガ(perl -de0)の話も詳しいです。 で、プロファイルの使い方。 例えば、foo.pl というプログラムをプロファイリング。 % perl -d:DProf foo.pl で、tmon.out というファイルができます。整形して見るには dprofpp。 % dprofpp Total Elapsed Time = 54.58411 Seconds User+System Time = 49.11048 Sec
【続】やはり Perl はメモリ喰いな言語。データ型の内部構造
以前、「やはり Perl はメモリ喰いな言語。データ型の内部構造」という記事を書いたことがあるのですが、自分で書いておきながらしばらく立つと完全忘却してました。時代は変わって、今仕事で運用しているサーバは、64bit 版のＯＳです。 最近になって、DB のテーブルのデータを加工・集計しながら CSV にダンプするってプログラムが、データ数が非常に多いときに、1.5 GByte ほどメモリを食いつぶしているってことに気がつきました。理由は至って簡単なのですが、結構ハマリどころなので備忘録として記事にしておくことにしました。 みなさん、仕事とかでは特にそうだと思うのですが、DBI の処理って何らかのラッパーを書いて使っていると思います。僕は適当に書くとよくやってしまいがちなのですが、イメージ的には、こんな処理の流れのコードを書いていました。 （・・・えっ？そんなへぼコード書いてない？？・・・す
やはり Perl はメモリ喰いな言語。データ型の内部構造
use Devel::Size::Report qw/report_size/; # 1bit, 1byte, 2byte, 3byte, 4byte(=32bit), 5byte my $b = [ 0, 0xFF, 0xFFFF, 0xFFFFFF, 0xFFFFFFFF, 0xFFFFFFFFFF ]; print report_size($b, { indent => " " }); # null, length=1, 2, 3, 4, 5 my $c = [ '', '1', '10', '100', '1000', '10000' ]; print report_size($c, { indent => " " }); Size report v0.10 for 'ARRAY(0x8c8bc28)': Array ref 192 bytes (overhead: 92 byte
[Perl] Encode Jcode UnicodeJapanese のベンチマーク比較 isoya9の日記-ウェブリブログ
「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧
大規模なeコマースサイトを Apache と mod_perl で構築する
この文書は Perl.com: Buildling a Large-scale E-commerce Site with Apache and mod_perl を翻訳したものです。2001年に書かれた文書であり、Apache/mod_perl/CPAN モジュールなど現在の状況にはそぐわない部分もある可能性があります。 大規模なeコマースサイトを Apache と mod_perl で構築する よくある神話 Perl はセーブする アプリケーションサーバの撰択 ケーススタディ: eToys.com Apache::PerlRun による救済 新たなアーキテクチャの計画 2000年のクリスマスを切り抜ける アーキテクチャ プロキシサーバ アプリケーションサーバ 検索サーバ ロードバランスとフェイルオーバー コード構造 キャッシング セッショントラッキング セキュリティ 例外(Excepti
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
Class::DBIで永続化が切れなくてハマった
WEB+DB PRESS vol33の「ライブドア構築ノウハウ大公開」でClass::DBIの永続化を切るには、Ima::DBIの内部でクロージャとして生成されるdb_Mainをオーバーライドすれば永続化を切ることができるという記述がありました。 これなんですが、先日あるアプリを作成しているときに、db_Mainをオーバーライドしても永続化されてしまうという現象にあいました。 いろいろ調べたり、にぽたんとかに聞いたりした結果、db_Mainをオーバーライドしているクラスで __PACKAGE__->set_db() もしくは __PACKAGE__->connection() をしていたのが悪かったということが判明しました。なぜなら __PACKAGE__->set_db() もしくは __PACKAGE__->connection() をすると、Ima::DBIではなくClass::DB
モジュールをuseした際のメモリ使用量(増加量)を調べてみる (iandeth.)
iandeth. Perl, Flash ActionScript, MySQL, Movable Type, システム開発 - そんなテーマのサイトdeth. gtop.plx #!/usr/bin/perl use strict; use warnings; use GTop; my $gtop = GTop->new; my $before = $gtop->proc_mem($$)->size; eval $ARGV[0]; die $@ if $@; my $after = $gtop->proc_mem($$)->size; my $diff = GTop::size_string($after - $before); print "$diff : $ARGV[0]\n"; 例） CGIモジュールのメモリ増加量は... $ ./gtop.plx 'use CGI' 704k :
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
http://rintaro.dip.jp/info/?c=pg&p=apbench
http://www.typemiss.net/blog/kounoike/20060212-64