一般的に言われている性能面で好ましくないロジックは

じゅん 2000/03/06(月) 16:22:05
こんにちは。今回もよろしくご指導をよろしくお願いします。
私はPerlを使い始めてまだ、４ヶ月くらいなんですが、今度、他の人が
作成したPerl APPの性能を上げるためにロジック調査をしなければなら
なくなったのです。
一概に性能はPerlのロジックだけのせいで悪いとは言えませんが、Perl
APPの面で修正できるところがあったら何かアドバイスをお願いします。
例えば、一般的にある関数を使うと性能が悪いと言われているとかの情報
がありましたら何でも結構ですのでよろしくお願いします。
ちなみにソースをさっと見た感じでは①Perl5でしか使えないロジックを
使用している②一つのAPPからJavaScriptを駆使していろんな違うcgiを
呼んでいる③多次元配列を使用している等が以前に自分が他プロジェクト
で作成したCGIとちがうと思います。
よろしくお願いします

無責任官庁 2000/03/06(月) 17:05:04
あまりに漠然としすぎてなかなか発言が難しいんですけども、
どんな言語・プログラムでも、一番のボトルネックになる部分って、
やっぱしＩ／Ｏの部分じゃないかと。

open(FILE,"hogehoge");
$data = <FILE>;
close FILE;

こんなのは論外でしょう。
（さすがに、そう極端なモノは無いとは思いますけど）
私はＰｅｒｌについてはあまり詳しくないので、ここからは
他の言語での経験から…となりますけども…
性能を追求するのであれば、一つの命令・関数で大量の機能を有する
モノってのは、あまり好ましくないようにも思えます。
これは、私の関わっていたプロジェクト（制御系アプリ開発）
では、Ｃ言語の“printf”系関数が全て使用禁止になっていることから、
ですが。
“printf”“scanf”に潜む危険・バグを考えないとしても、
これらの関数はあまりに無駄が多すぎる…ということでしょうか。

Syn [E-Mail] 2000/03/06(月) 17:20:33
Perl ではないのですが、プログラムの最適化とゆー観点でおもし
ろいサイトをご紹介しますと、

C プログラミング診断室
http://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

です。

＞無責任官庁さん
printf 、ダメですか!?(^^; mem 系はわかるけど…
あ、制御系なら mem 系のほうが使用頻度高いのかな。

ＥＭＩ 2000/03/06(月) 17:55:39
やはり、Perlならば怠惰・短気・傲慢の精神からはずれたプログラムが悪いプログラムと言えるでしょう。（笑）
＃Perlに限らないけど。
ただし、偽の怠惰・偽の短気・偽の傲慢に基づくプログラムはだめなプログラムです。（笑）
＃やっぱりPerlに限りませんが。

参考：ラクダ本(:-p

さだひろ 2000/03/06(月) 20:01:36
すみません．ちょっと確認したいのですが＞無責任官庁さん
＞open(FILE,"hogehoge");
＞$data = <FILE>;
＞close FILE;
@data = <FILE>;でもだめですか？
つまり，<FILE>がバカでかいとまずいよという，あれでしょうか？

無責任官庁 2000/03/06(月) 21:50:47
> <FILE>がバカでかいとまずいよという，あれでしょうか

ちょっと書き方がアレでしたけども（急いでたもんで失敗…）(謎)
ようするにそういうことですね。
改行云々ってのは、考えないことにしてください（汗）
要は、Ｉ／Ｏは必要最小限にしましょうと、そういう意味で、です。

> printf 、ダメですか!?

printfを自力で実装しようとした時のコードの量を考えると、
これほど無駄なモノは無い…と。そんな所でしょうか。
それと処理系の問題かもしれませんけど、バグも結構潜んでいるようでしたね。
これらの関数には。（デカいだけあって、それもしかた無いのか…）

> 怠惰・短気・傲慢の精神からはずれたプログラムが悪いプログラム

なかなか的を得たいい言葉だと思います。一票。
ただ意味を取り違えると大変なモノにもなりそうですね。

B-Cus 2000/03/06(月) 22:12:37
> ①②③
機種依存文字です。使っちゃだめ。

こういうのも指摘してくれませんか＞回答者の方々

視覚障害者のアクセシビリティも大事だけど、非 DOS/Windows 環境を
使う人間のアクセシビリティの向上も大事でしょ。ま、
　「視覚障害者に優しい web page を！」
と叫ぶ方が気持いいのかも知れんけどさ。

shin' 2000/03/06(月) 22:43:33
>多次元配列を使用している

ファイルをメモリに読み込むとかは配列のサイズに
ファイルサイズが依存することになってしまうので、
やめたほうがいいのじゃないかなと思います。
perlを用いる場合、ファイルアクセスのスピードと、
バッファ（メモリ）を多く消費するというのは、
どちらがいけないことなのでしょうかね。
僕もみなさんの意見をお聞きしたいです。

いずれにせよ、インタプリタ言語での最適化とかいうのは
非常にマニアックになってくるのじゃないかなと、
個人的に思います。

ex)BASICインタプリタだと、
PRINT 4*2
より
PRINT 4+4
のほうが早いらしい。

わけわかりませんね。:-)

猫（テレホ無し） 2000/03/06(月) 23:51:35
私が計ったわけではないですが(ActivePerlぢゃないので)参考になるかもと思って。
http://www.din.or.jp/%7Ehagi3/Perl/Perf.htm

andi 2000/03/07(火) 01:14:38
「性能」の定義によるかもしれませんが、
Perl5専用スクリプトってダメなんすかね・・・
多次元配列も時と場合によっては必要かと。

まぁ一般的に性能面で好ましくないと言われるのは
やはりループ内の無駄な処理でしょう。
Perlに限らないんでダメ？

andi 2000/03/07(火) 01:18:15
自分あまり詳しいわけではありませんが、

>PRINT 4*2
>より
>PRINT 4+4
>のほうが早いらしい。

っつーのは基本的にコンピュータは加算しか出来ない
ためではないでしょうか。

Ichi 2000/03/07(火) 05:27:48
>無責任官庁さん
>open(FILE,"hogehoge");
>$data = <FILE>;
>close FILE;
>
>こんなのは論外でしょう。

まぁ、一般的には論外ですけど、$data = <FILE>;とすることによって
一時ファイルを使用しなくても良くなるなら、この方法にも価値があると
思います。(メモリは大量消費しますし、確かにFILEも大きすぎてはダメですが)

例えば、掲示板でレスのついた発言を上に持ってくるとか。
(この場合は、メモリの大量消費が問題ですね)

性能面で好ましくないロジックは、検索時に、最初のデータから
順に一致するまで比較することでしょうか。データをソートして
おけば、もっと有効な手段があります。簡単なところでは二分
探索法とか。

言うまでもありませんが小さな改変より、アルゴリズムを見なおすと、
数百倍速くなることすらありえます。

じゅん 2000/03/08(水) 15:35:16
[[解決]]
皆様ありがとうございました。
無責任官庁さんが指摘されていたロジック
open(FILE,"hogehoge");
>@data = <FILE>;
>close FILE;
をいたるところで使用していますのでそこらへんを修正していきたい
と思います。

Ichi 2000/03/09(木) 06:11:54
>無責任官庁さん
>open(FILE,"hogehoge");
>@data = <FILE>;
>close FILE;
は、hogehogeが十分に小さいファイルであることがわかっているなら
ありですよね？

[上に] [前に] [次に]