アカウント名:
パスワード:
パフォーマンス、速度に関することって優先度低いんだなー。コードでの最適化は置いておくとしても、適切なアルゴリズムを採用しているかどうかって最重要ではないの?ダメなアルゴリズムを採用したら、どうこねくり回しても読みにくく、バグが多く、遅い物にしかならないと思う。
性能にインパクトを与えるようなところでは後からアルゴリズムを変更できるように、IFなどで切り離して書かれてるのがいいコードだとは思います。
2015年現在においては、コーディングレベルでのパフォーマンス要求の優先度は実際に低いのでしょうね。これから作られる100%近く(無論全てではないですが)のプログラムにおいて、可読性、テスト容易性に対しパフォーマンスを優先して考える必要はなくなっているのだと思います。
例えば、数百件程度の要素検索であれば、線形検索で済ませてしまってもほとんど問題ない程度に。
絶対的なパフォーマンスを考慮すべき状況ではまずネイティブ言語を採用するべきなので、そうでない言語が使用されるプロダクトでは、高速なアルゴリズムの選択の優先度は2の次という判断が妥当となってしまうのだと思います。
あなたも読みやすさやバグの出やすさのほうが速度より先に書いてるじゃないですか。
読みやすさ、バグの出やすさに影響するのがアルゴリズムの選択だと思うのです。例外処理をきちんと行うことは重要なのですが、そもそも例外処理が少ないアルゴリズムを選ぶほうが優先度が高いのではないか、そういうことが言いたいのです。
そういう点なら、Java7やAndroidに組み込まれており、盛大にバグっている [srad.jp]ことが判明したTimSort [preferred.jp]なんかは、保守性最悪のアルゴリズムじゃないかと思ってしまいますね。
ものによると思うけど、パフォーマンスは優先度低いでしょう。(要求仕様にx分間に何件のデータを処理するとか明記されているものは優先度高いと思うよ)まず正常に動くこと。そのあとでパフォーマンスを上げていけば良い。大抵は設計時点でどのアルゴリズムを使用するか決まっていると思うし、パフォーマンスを上げる為にアルゴリズムを変更すると、再設計が必要になることも考えられるが、よほどのことが無い限り、そんなことにはならないと思う。
> ダメなアルゴリズムを採用したら、どうこねくり回しても読みにくく、バグが多く、遅い物にしかならないと思う。
アルゴリズムと設計を混ぜて考えているように思うのですが、遅いのはアルゴリズムの選定が間違っているから。バグが多くなるのは設定がダメだからであって、アルゴリズムがダメなわけではない。
# ダメなアルゴリズムって意味不明なんだけど、# 正常に効率よく動作するからアルゴリズムって言われるんでないの?# 正常に動かないものはアルゴリズムって言わないと思う。
× バグが多くなるのは設定がダメだからであって○ バグが多くなるのは設計がダメだからであって
アルゴリズム=手順効率がいい物だけを特別にアルゴリズムと呼ぶわけではない。効率がいいアルゴリズムもあれば、効率が悪いアルゴリズムもある。正常に動くアルゴリズムもあれば、動かないアルゴリズムもある。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
適切なアルゴリズム (スコア:0)
パフォーマンス、速度に関することって優先度低いんだなー。
コードでの最適化は置いておくとしても、適切なアルゴリズムを採用しているかどうかって最重要ではないの?
ダメなアルゴリズムを採用したら、どうこねくり回しても読みにくく、バグが多く、遅い物にしかならないと思う。
Re: (スコア:0)
性能にインパクトを与えるようなところでは後からアルゴリズムを変更できるように、IFなどで切り離して書かれてるのがいいコードだとは思います。
Re: (スコア:0)
2015年現在においては、コーディングレベルでのパフォーマンス要求の優先度は実際に低いのでしょうね。
これから作られる100%近く(無論全てではないですが)のプログラムにおいて、可読性、テスト容易性に対し
パフォーマンスを優先して考える必要はなくなっているのだと思います。
例えば、数百件程度の要素検索であれば、線形検索で済ませてしまってもほとんど問題ない程度に。
絶対的なパフォーマンスを考慮すべき状況ではまずネイティブ言語を採用するべきなので、
そうでない言語が使用されるプロダクトでは、高速なアルゴリズムの選択の優先度は2の次という判断が
妥当となってしまうのだと思います。
Re: (スコア:0)
あなたも読みやすさやバグの出やすさのほうが速度より先に書いてるじゃないですか。
Re: (スコア:0)
読みやすさ、バグの出やすさに影響するのがアルゴリズムの選択だと思うのです。
例外処理をきちんと行うことは重要なのですが、そもそも例外処理が少ないアルゴリズムを選ぶほうが優先度が高いのではないか、そういうことが言いたいのです。
Re:適切なアルゴリズム (スコア:1)
そういう点なら、Java7やAndroidに組み込まれており、盛大にバグっている [srad.jp]ことが判明したTimSort [preferred.jp]なんかは、保守性最悪のアルゴリズムじゃないかと思ってしまいますね。
Re: (スコア:0)
ものによると思うけど、パフォーマンスは優先度低いでしょう。
(要求仕様にx分間に何件のデータを処理するとか明記されているものは優先度高いと思うよ)
まず正常に動くこと。そのあとでパフォーマンスを上げていけば良い。
大抵は設計時点でどのアルゴリズムを使用するか決まっていると思うし、
パフォーマンスを上げる為にアルゴリズムを変更すると、再設計が必要になることも考えられるが、
よほどのことが無い限り、そんなことにはならないと思う。
> ダメなアルゴリズムを採用したら、どうこねくり回しても読みにくく、バグが多く、遅い物にしかならないと思う。
アルゴリズムと設計を混ぜて考えているように思うのですが、
遅いのはアルゴリズムの選定が間違っているから。
バグが多くなるのは設定がダメだからであって、アルゴリズムがダメなわけではない。
# ダメなアルゴリズムって意味不明なんだけど、
# 正常に効率よく動作するからアルゴリズムって言われるんでないの?
# 正常に動かないものはアルゴリズムって言わないと思う。
ゴメン誤字った (スコア:0)
× バグが多くなるのは設定がダメだからであって
○ バグが多くなるのは設計がダメだからであって
Re: (スコア:0)
アルゴリズム=手順
効率がいい物だけを特別にアルゴリズムと呼ぶわけではない。
効率がいいアルゴリズムもあれば、効率が悪いアルゴリズムもある。
正常に動くアルゴリズムもあれば、動かないアルゴリズムもある。