質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
パフォーマンス

コード効率の向上や計算に関する質問には、このタグを使ってください。

プログラミング言語

プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。

Q&A

解決済

17回答

3630閲覧

パフォーマンスと生産性のトレードオフ

raccy

総合スコア21733

パフォーマンス

コード効率の向上や計算に関する質問には、このタグを使ってください。

プログラミング言語

プログラミング言語はパソコン上で実行することができるソースコードを記述する為に扱う言語の総称です。

3グッド

3クリップ

投稿2016/09/29 22:33

編集2016/10/08 12:59

とある技術系ブログっぽいところで、とある人の意見で「パフォーマンス(性能)が遅くなることをわかっていてその技術を採用することはプロとして失格」というのを見たことがあります。でも、実際はパフォーマンス(性能)と生産性はトレードオフの関係になっていて、必ずしも実行速度最速を選ぶことが最適とは限らないと思っています。

例えば、言語の速さで言えば、(コンパイラの最適化以上に凄いことができる人が書く)アセンブリ > C > C++ > Java ≒ C# >> JavaScritp > Perl ≒ Python ≒ PHP ≒ Ruby という感じでしょう。
参考: fast? (64-bit Ubuntu quad core) | Computer Language Benchmarks Game
しかし、上の順番とほとんど逆の方向で、実行のしやすさ、メモリ領域の安全性(GCがあるとか)、抽象度の高さ等により、生産性は高くなると思います。また、同じ言語でも、例えばC++でメモリを確保(new)し、ポインタで管理する場合は二つのパターンがあります。

  • 生ポインタ … メモリ解放を自分で制御する必要があり、注意深いコーディングが必要。
  • スマートポインタ … 循環参照にならければ、不要になった時点でメモリ解放されるため、GCに近い生産性がある。ただし、参照カウンタの処理が入る分だけ、生ポインタより遅くなる。

他にもライブラリやフレームワークの選択なども、遅いけど使いやすい、速いけど使いにくいというのはあり得ます。このように、言語やコーディングの仕方、使用するライブラリの選択において、パフォーマンスと生産性のどちらを取るのかはトレードオフになっていると思います。

そこで、質問です。実際に作るときに、どこまでパフォーマンス(性能)を求めるべきなのでしょうか?たとえば、とある新サービスのWebシステムを作るにあたって、

  • 想定平均応答時間: 1.0秒以内
  • 想定工数: 6人月以下

とあったとき、計画が4つあり、それぞれの見積もりが下記のような感じだったとします(言語とフレームワークは、CPollとか使ったことが無いので、ぶっちゃけ適当です)。

  • Sプラン(C + アセンブリ / フルスクラッチ)

応答時間: 0.1秒、工数: 12人月(スーパーハッカー雇用)

  • Aプラン(C++ / CPoll)

応答時間: 0.5秒、工数: 6人月

  • Bプラン(Scala / Play Framework)

応答時間: 1秒、工数3人月

  • Cプラン(Ruby / Ruby on Rails)

応答時間: 2秒、工数2人月

予算を超えてでもSにすべきか、予算内でなるべく最高にすべくAにすべきか、仕様さえ満たすのだから、経費削減のためにBをすべきか、実際流行るかどうかわからないため、とりあえず作ってから考えるためにCでやっちゃうかです。なお、ただのプログラマーの立場では無く、プランを選ぶ顧客や経営者の立場、または、そのような人への意思決定に影響を与える形で意見を述べるまたは決定権を与えられた技術系担当者の立場(CIOまたは実質的なCIOである立場、外部からの場合はコンサルやSIerのような立場)であるという想定でお答えください。また、見積もりはあくまで想定であり、実際に作ったら想定以上になることもあり得ます。そういった、リスクも込みでお考えください。


【補足】

皆さん共通の疑問点などを補足します。

  • 「プロ失格」について

荒れている記事がさらに荒れる事になりますので、出典は明記しません。また、一字一句同じというわけでは無く、そのようなニュアンスだったと言うことです。ですので、ググっても引っかかりません。
状況としては「○○はパフォーマンスが悪い、パフォーマンスが悪い技術を使うのはレベルが低い素人、なので、○○を使うのは素人」という感じの発言です。記事全体としては、コレに相当するような内容なので、皆さんにお教えするような価値はありません。
ただ、ここ2〜3ヶ月ほどパフォーマンスの良さ/悪さについて考えさせられたきっかけであり、そこからこの質問に繋がった事でもあるので、最初に記述させていただきました。

  • 想定や見積もりについて

あくまで例だと思ってください。工数や秒数とかは適当ですので、大きさの比較以外に深い意味はありません。状況としては、これから企画として立ち上げ予算取りや仕様決めをする段階だと思ってください。想定平均応答時間と想定工数も確定した物では無く、最初にこれぐらいだといいなーと思ったぐらいの値です。Sプランの工数もCプランの平均応答時間も戦略的には許容できる範囲内という感じです。実際はサーバの台数やスペックだとか、保守・運用やソフトウェア(OSやDB等)の料金とかそういうのも総合的に判断する必要がありますが、話を簡単にするために、そういった物を省いています。

i50, LLman, Orlofsky👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

zico_teratail

2016/10/01 07:19

「工数や秒数とかは適当」とのことですが、そういう前提条件ではこの質問への解は導けないと思います。前提によって最適解は変わるので。
raccy

2016/10/01 07:54

話を簡略化するために、秒数と工数の大きさのみに絞っているだけです。例はあくまで例であって、それにそった形でなくても全然かまいません。パフォーマンスや生産性とは関係無い前提条件(例えば、プロジェクトの重要度や企業の体質等)があれば、それをあげていただきたいと思います。厳密解の回答が欲しいのでは無く、どのように考えるべきかの回答が欲しいのです。
raccy

2016/10/01 07:57

もちろん、「より厳密なパフォーマンスや工数の見積もり」が前提条件で、それがなければ判断できないというのであれば、それはそれで回答だと思います。
zico_teratail

2016/10/01 08:00

プロジェクトの重要度は非常に大事な前提条件だと思います。ちゃちゃっと開発して市場の様子を見るだけなのか、社運を賭けて全力でやるのかで違いますし。
raccy

2016/10/01 08:04

その内容をぜひ、回答の所に書いていただくようお願いします。
zico_teratail

2016/10/01 08:10

自分の回答(のコメント欄)に既に書きました。「何をするのか≒プロジェクトの規模や重要度」によります。
raccy

2016/10/01 08:26

すいません「何をするのか」だけでは、何を重視しているのかの意図が読み取れませんでした。単純に「個別に検討する必要があり、一般化は不可能」と言う意味で捉えてしまいました。
zico_teratail

2016/10/01 08:29

ちょっと何をおっしゃっているのか分かりません・・・。結局何をご質問されたいのか理解できずすみません。
raccy

2016/10/01 14:21

端的に言うと、聞きたいのは「どこまでパフォーマンスを求めるべきなのか?」です。zico_teratailさんがいうように、プロジェクトの重要度や規模を考慮しないと判断できないというのも一つの回答だと思っていますので、ちゃんと理解されて回答されていると思っているのですが…。
think49

2016/10/04 04:58

「プランを選ぶ顧客や経営者の立場、または、そのような人に意見を述べる技術系担当者の立場であるという想定」とありますが、前者(経営者)と後者(技術者)で意見が変わる気がします。 回答を貰う際にどちらの立場で回答するかで全く変わってくると思うので、「技術者目線では~」や「経営者の立場では~」の前置きがないと「参考にならない回答」となるように思うのですが、この辺りはどのようにお考えでしょうか。
raccy

2016/10/08 04:39

ただの雇われ技術者の場合、「それは上(顧客や社長)が決めること」「仕様で決まっている」で終わってしまうので、それを避けるためにこのような書き方をしました。想定している技術者は戦略を含めてほぼお任せされている人と考えています。実際に顧客や経営者が技術に詳しいとは限らず、トータル的なリスクを含めて、どのような戦略すべきかを意見を求められることは多いかと思っています。
guest

回答17

0

ベストアンサー

ミクロ経済学的な考え方になりますが、価値関数を通してパフォーマンスと生産性を同じ単位の数字に変換する(たぶんもっとも適切な単位は多くの場合、損益額)のが有用かと思っています。

もちろん価値関数は線形な関数ではないでしょう。生産性の方では納期を守れるかどうかのあたりに急峻な傾斜があり、パフォーマンスの方は非機能要件を守れるか(以下略

パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格

「プロ失格」ではなく「競技プログラマ失格」くらいが適切なんじゃないかと思いました。


追記です。マイナス評価をいただいているのですがこの意味は「質問者の質問そのものに答えていないじゃないか」という批判であろうと解釈して。

この回答は私なりに正面から答えたつもりです。選択肢のどれが良い、ではなく当事者として選択肢から誰か選ぶ必要があるならどういうアプローチをするか、です。
逆に言えば提示された選択肢だけではまだ背景の文脈情報が足りておらず、当事者にしか述べられない価値関数のカーブ(さらには不確実性の大きさ)といった追加情報が必要でしょうという見解になります。

価値関数なんていうミクロ経済学用語はねーよという批判だったらごめんなさい、普通は効用関数って言いますか。無教養さらして汗顔の至り。

投稿2016/09/29 23:13

編集2016/10/08 03:57
yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

sharow

2016/10/08 11:49

+評価入れた一人ですが、その理由は「生産性」は経済の話だというところにとても同意できるからです。これは技術フレーバーのかかった経済の質問だと思います。もし経済的観点を抜きにした質問なら、「好きなもの or 一番早くできるもの」になってしまいます。 生産性の高といわれるRailsで作られたゴーストサイトが成立する理由は、ツール/言語は付加価値と直接的な関係が無いからです。応答時間も直接的な関係はありません。というか、直接的な関係でモデル化できるほど世界はシンプルではないと思います。趣味ならゴーストサイトでも「Rubyだから生産性が高かった」と言えるのかもしれませんが、経済主体としてそれを言うには隣にツッコミ役の待機が必要です。 これは経営者に助言する立場だったとしても、時間を費やす情報交換や議論を必要とする部分だと思います。当事者として質問を捉えると、私もそう考えてしまいます。 (技術要素入りであっても経済寄りの質問をここですべきでない、というような意図は含んでいません。teratailは推奨しないのかもしれませんが…。)
raccy

2016/10/08 13:46

経済学的観点というところからベストアンサーにさせていただきたいと思います。sharowさんのコメントにもとても同意します。考えてみれば、teratailにそぐわない質問だったのかも知れません。ですが、そのような顧客や経営者に立った立場も考えておくべきと質問させていただきました。そんな質問に、参考になるたくさんの回答を頂いて、考えが深まりました。この場をもってお礼させていただきます。
guest

0

Bプランがいいと思います。
理由としては「応答時間の要求を満たしている」のと「工数に3カ月のマージンがある」ことです。また、今後の「保守契約」や「バージョンアップ」を考えてもBプランは一番いいのかなと感じます。

Sプランは性能は抜群ですが、コストが想定の2倍必要となり、スーパーハッカーが参加した高度なプログラムを性能を維持しつつ保守するのは難しいと思います。
Aプランは性能とコストを満たしますが、工数が想定工数と一致してしまいリスクがあるのが気になります。
Cプランはコストを満たしていますが性能が要求を満たしていないので選ぶべきではないと思います。

学問は知見を得るためにいろいろな制約を度外視して実装することもあります。一方で商売は利益を得るためにコストを考えないといけませんね。求める方向性が違うので、やはり学問と商売は別に考えるべきだと思います。

投稿2016/09/30 00:15

yona

総合スコア18155

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

こんにちは。

私なら、原則、リピーターが大きく減らない範囲でできるだけ初期投資を抑え、かつ、サービス開始を急ぎます。

平均応答時間の1秒と3秒の差はUIの作り方であまり気にならないようにできる場合もあります。それが可能ならリピーター率への影響はあまりないと予想されるのでCプランでできるだけ速くサービス開始するでしょう。
その差が決定的になる場合は予算内で性能を最適化できるAプランを選ぶ可能性が高いです。3秒を気にならないようにできない時、0.5秒と1秒の差は操作していて「サクサク動いて気持ちが良い」と「普通」の差がでると思います。リピーター率にも影響するでしょう。

0.1秒まで縮めることでコンペティターを引き離せる見込みがある場合はSプランも検討するかもしれません。でも、リスクが大きいです。それを補ってあまりあるほどの効果がでる見込みが立たない限り選択するべきでないと思います。
でも、技術者としてはつい選択したくなりますね。自分のお金を使う時なら誘惑に勝てない時もありそうです。しかし、人のお金を使う時ならそれこそ「プロ失格」です。

「パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格」

中途半端に分かっている素人さんの見解ですね。
そのような人がクライアントになった時が一番頭が痛いです。

投稿2016/09/30 01:04

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ケースバイケースになるのではないでしょうか。
例え保守性が悪くなったとしても他社製品の処理速度に負けられない場合は、やむなく処理速度を優先する選択をするかと思います。
逆に、リリースして終わり、ではなく継続的に改善していくようなプロジェクトであれば処理速度よりも保守性をとるのではないでしょうか。

もワンサイズ大きな枠としての、経営の目線で考えた場合の議論が必要に思います。
処理速度優先の危険なコーディングは、速度では他者に勝っても果たしてバグを引き起こさずに満足いく稼働をし、消費者に受けられ続けることが出来るだろうか。

安全な設計にしたところで無難な製品しか作れないのであれば、消費者は安定稼働を評価してくれるだろうか。

などでしょうか。書いてて思いましたが、安定している方が私は好きですね。
go言語はそこを意識して作られた、みたいなあやふやな知識が頭の中にあります。
あまり参考にならないかもしれませんが。。

投稿2016/09/29 23:50

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/09/30 00:03

追記 すみません、よく読まずに書いてしまいましたが、立場を想定して、とありましたね。 失礼いたしました。 顧客側の立場としてはcプランです。 ソフトウェア制作会社の経営者としてもcプランです。 無理な提案を押し通して失敗した場合次の仕事がなくなりかねません。 技術者責任者としてはaプランです。 スーパーハッカーに依存してしまうと何かあったときに人材を確保できないと泣く羽目になりそうです。 技術者としてはsプランです。 スパハカさんに質問しまくります。 予算確保してくれてありがとうです。 こんなところでしょうか。
guest

0

そもそも「Cじゃないと遅くてやってられない」という状況なんか滅多にないのでは?

たとえばPHPで2秒もかかる処理なんて見たことないです(ネットワークの応答待ちなど相手側の問題の場合を除く)。
ただし特殊な状況としてたとえば画像の処理なんかはメモリも大きく食うし処理時間もかかりますが、そういうのはそれこそCで書かれた既存ライブラリとかをPHPやRubyから呼び出して使えばいいですよね。

ハードが未熟だった時代ならともかく、現代でまだ「速度ガー メモリ節約ガー Cガー」などと言ってるのは頭の古いオジサンかプログラミングオタクのどちらか。

世界最大規模のFacebookですらPHPが元になった言語を使っていて問題なく動いているのに、わけのわからない新サービスのWebシステムで速度にこだわって生産性等を犠牲にしてまで言語にこだわる必要がどこにあるでしょうか?

流行るかどうかもわからない新サービスはとにかく生産性重視で開発する以外の選択肢など考えられないです。もし流行って、なおかつ速度に問題が出てから初めて対策を考えればいいでしょう。スケールするなり言語を変えて書き直すなり。
どうせ新サービスなんて10に1つも上手くいかないんですから、初めから万全の体勢でやっても金と時間の無駄です。

また、どうせスーパーハッカーを雇うなら、CではなくてLL言語でスーパーな人を雇うべきでしょう。なぜなら、もしその人が倒れたり辞めたりした場合、Cだと後継者が見つからず、誰もソースを全くいじれなくなるかもしれないからです。LL言語なら多少レベルが落ちたとしても人数が豊富なので代わりが見つかりやすい。

投稿2016/09/29 23:38

zico_teratail

総合スコア907

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

zico_teratail

2016/09/30 03:05

他の方も書いていますが、Web系では言語よりもむしろDBのほうがボトルネックになる。 DBの設計やチューニングに詳しい人を最低でも一人は確保すべき。
zico_teratail

2016/10/01 07:18

「工数や秒数とかは適当」とのことですが、そういう前提条件ではこの質問への解は導けないと思います。 「プロ失格」と言っている人の主張は、「F1マシンがあるのに遅い軽自動車に乗るヤツはレベルが低い素人。近所のコンビニに行くのでもF1マシンに乗るのがプロ」などと言っているのに等しい。 しかし実際は前提条件(近所のコンビニに行くのかサーキットで走るのか)によって最適解が違うわけで、前提となる工数や秒数、なにを作るのか等が適当では回答のしようがありません。
guest

0

プランを選ぶ顧客や経営者の立場

という前提でしたら、Cプランですね。


なぜかと言えば、Cプランで3本リリースした方が、
収益が上がる確率が高いと見込まれるからです。
それは、サービス(初期)の収益は、性能に比例しないからです。

そして、収益の見込みのないサービスは畳んでいきます。
もし、ヒットしたサービスがあれば、収益が見込めるので、
あらためてBプラン(以上)で書き直します。

じっさい、Webサービスはそういう事例が多いです。
たとえば、TwitterはRubyからJavaやScalaに書き替えてますよね。

これは、アジャイルの延長線上で、事後的に再設計する考え方です。
クヌースの名言「早すぎる最適化は諸悪の根源」も適用できますね。

Cプランのデメリットも言えば、「想定平均応答時間」を下回ってます。
しかし、経営レベルでは、仕様も絶対ではなく、ビジネスが優先です。
なにか重力加速度みたいな自然法則ではなく、人間が要件定義するものなので。

けっきょく、収益が上がらないと、保守しきれず、想定より重くなったりします。
逆に、収益が上がれば、後からチューニングして、「想定平均応答時間」を上回れます。

まあ、今でも組み込みとかの分野だと、ミリ秒単位の
シビアな性能要件を要求される場合もあるでしょう。

しかしWebは、とくにソシャゲとか考えてみれば、
面白いゲームなら重くても人が集まりますよね。
「反応が1秒遅い」からやらない、とかはない。
(もちろんサーバが落ちたり、DBが破損するレベルなら別問題ですが)

かりに重さが問題になるとしても、ボトルネックになりやすい
DBをチューニングした方がはるかに効率的です。
あとHTML、CSS、JSのフロントまわりでも工夫の余地はありますし。

最後にまとめると、面白さはユーザが評価するので、不確定要素です。
それなら、市場探索的に数を多く出し、多様性を求めたい。
つまり、強い恐竜より小さなネズミが氷河期を生き残るイメージです。

投稿2016/09/30 04:43

編集2016/09/30 04:50
LLman

総合スコア5592

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格

見方が一面的というのか、考えが古いような気がします。
「考えが古い」というのは処理時間へのこだわりを感じたからで、昔コンピュータリソースが貧弱だった頃のテクニックを駆使して処理時間を短くすることに意義があった時代の名残なのかな、と受け止めました。

また「生産性」という言葉も、徹頭徹尾未来永劫自分一人で開発・保守をするつもりなのか、組織としてやっていくのか、どちらなのかによって捉え方が変わってくると思います。
私は後者の経験しかありませんがその観点でいうと、将来的な保守性の良さや属人性の排除も「生産性」の評価基準に含まれると思います。
後で他のメンバーがコードを見た時、パッと見分かりづらいとか、特定の人でないとメンテナンスできないものを「生産性」が高いとは言いづらいです。

また商売的な観点では、前提条件として「応答時間1秒、工数上限6人月」ということであれば、(Webシステムでは体感上差がないと思われる)応答時間1秒を0.5秒にするために案件を赤字にするのは組織としては許容されないと考えています。
どこまでパフォーマンスを求めるか、は売る側としては「お客との握り次第かな」と思います。

皆さんご承知かと思いますが、大抵開発案件は想定通りの工数で収まらないことを考えると、私としては安全を見込んでBプランなのかな、と思います。
※raccyさんと同じで、開発言語は無視してます。Scala触ったことないので。

投稿2016/09/29 23:44

ynakano

総合スコア1894

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

最新のWebサーバーはクラウドが主なので、
インスタンスをスケールアップすれば十分です。
そうだRubyでちゃちゃっと作って、一番高いインスタンスで動かせばいいじゃん、アタシ天才!


プログラマーはプログラミングで問題を解決することが仕事です。
プロはお金を稼ぐものなので、お客様の要望(ニーズ)を満たす事が仕事です。
よって、プロのエンジニアは期間内に客の要望を満たすシステムを作る必要があります。

「パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格」
よって誤りですが、そのブログ記事を執筆した人がどんな文脈・意図で発したしたかは気になります。

なんでもC言語、アセンブラという話なら呆れるだけですが、
同じ言語でも似たようなライブラリを比較してみる、ループ文の書き方を工夫してみる、といったようなちょっとの意識でパフォーマンスが変わる事もありますからね。

経営者視点

経営者の立場から言えば1日でも早く製品をリリースする事が重要です。
1ヶ月先に似たようなサービスを別の企業に出されるだけで流行る・流行らないの決定的差にもなり得ます。

またどんなに優れた顧客や経営者も、草案レベルで本当に望んでいるものを正しく描ける人は皆無です。
絶対に手戻りが発生しますので手戻りは込みで考えるべきでしょう。
リリースが6ヶ月後と固定されているケースだとしても、Rubyで2ヶ月で出せるならば残りの4ヶ月で大規模なユーザーテストを実施したりするなど、UI・UXを含めて作り込めます。

理想はC、許容範囲はB、論外はA・Sとなります。
でも平均1秒という要件がなぁ…という訳で現実的な選択肢としてBを持って技術担当へ行くことになるでしょう。

でもこんな人が技術担当なら嬉しいなぁ

いかに手を抜きつつニーズを満たせるかでしょうね。
Rubyが得意な現場ならC一択です(Scalaが得意ならBがいいんじゃないですかね?)

さて、Rubyを選んだ場合平均1秒はどうすんねんという問題が残ります。
最近ではDocker(コンテナ)の登場もあり、複数の言語や技術を同居させても干渉を抑えられる時代になりつつあります。
その前提で細分化を進めていくと、以下のような感じの流れになりそうですね。

  • 全ての処理に同じ時間が掛かるわけではない、Rubyでも1秒以内に終わる処理も沢山ある
  • ボトルネックだけ探して叩けばよくね?
  • そもそも平均って何? 多少は妥協出来る処理と出来ない処理があるの?
  • 1秒の根拠って何? ヒアリングしたら集計結果をあまり待たされたくないらしいよ。

Dockerのお陰で対応するWebサーバーをURLで割ったり出来るので、
どうしても拘る部分を探して、そこだけ速い言語で書けば良いんじゃないですかね?
イヤイヤじゃなくて、現場の各メンバーの理想やモチベーションを意識して選択していく事が望ましいでしょう。

妥協じゃなくて、理想を元に粘り強く擦り合わせてくれる上司が欲しいです。
私?イエスマンなんで無理です。


Webサービスというのはただの一例ですが、ゲームだってアプリだって、みんなこの方式ですしね。
Windowsのアプリなら基本的にC#で組んで、3D扱うならDirectXやUnityみたいな…
WebサービスもDockerの出現で柔軟な言語選択が出来るので柔軟に対応出来るのが理想の世界になるかと思います。

投稿2016/09/30 05:17

編集2016/09/30 05:33
miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

求められる環境によって回答は異なるかと思いますが、現実的には
普通の企業環境ではBやAで十分な気が致します。特殊事情で余程の
パフォーマンスを求められていたり予算に余裕がある場合はSを
めざすという考えもあるというのが私の直感的な見解です。

それこそ現実的トレードオフの話です。

投稿2016/09/30 02:06

Yatsurugi

総合スコア1628

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Yatsurugi

2016/09/30 02:32

Cでも十分ではないかという考えもあるかと思います。 でないとRuby/Ruby on Railsや更に遅いJavaのStrutsなどの Frameworkは全く使えないということになってしまいます。
zico_teratail

2016/09/30 03:04

私はむしろ「C以外ありえない」という考えです。 速度が気になるなら無理にフレームワーク使う必要すらないです。
Yatsurugi

2016/09/30 03:46

現実問題としてはzico_teratailさんの考えも間違いではないかと思います。 但し、raccyさんはそもそも前提条件として 想定平均応答時間: 1.0秒以内 想定工数: 6人月以下 が求めらているということなのでそれを前提に回答を したということになります。
zico_teratail

2016/09/30 04:50

そうですね、いろいろなお考えがあるかと思います。 ただ質問者さんの前提条件がそもそも現実離れしているというか、根拠に乏しく思い込みで勝手に数字を決めているというか・・・。 Cだと0.1秒、Rubyだと2秒かかるWebサービスの処理って、具体的にいったい何なのでしょうね?
Yatsurugi

2016/09/30 07:28

質問者のraccyさんが敢えてmission criticalな条件のシステム設計を 求められて投稿されている可能性もございます。それ故に実の所、 回答の仕方が難しいところです。
ynakano

2016/09/30 07:39

raccyさんは「言語とフレームワークは適当」とおっしゃっているので、応答時間とプログラミング難易度の例として挙げただけなのではないかと思います。
zico_teratail

2016/09/30 16:54

例の挙げ方が雑というか古いというか・・・
raccy

2016/10/08 13:22

そのAかBのどちらなのかが一番聞きたいことだったのですが。
guest

0

###取引は相手方があってのことです。これを忘れることの方が真に「プロ失格」です。

「プロ意識」は成果物に対するものではなく、取引の相手先に向けるべきものです。仕事は物のためにするわけではなく人のためにすることです。

もちろん、トレードオフ問題のない同条件下であるならばより良いものに越したことはありません。ただし、現実には「費用」が必要となるため、実際は同条件とはなりません。顧客がサービスの恒常的な提供を求めるならば保守容易性も必要ですし、「即座に作れ」というのが先方の希望かもしれません。仰る通りトレードオフ問題です。要するに、先方と協議すべき課題です。条件が確定していない以上、最適解が出るわけがない(そもそも定義できない)です。

###この件に関わらず、一般に取引には利益と費用がつきまといます。
利益だけ見せびらかして契約を取り付けたが、実際は費用の方が大きかった」というトンデモケースも見たことがあります。(趣味ならば良いとしても)これでは経済活動として成立しませんのでこの場合も「プロ失格」であるといえます。この性質上、「素人の成果物」が「プロの成果物」よりも質で上回る可能性もあります。

###裏を返して言うと・・・
一般的にどの業界であれ、プロになると金銭面に加えて「シガラミ」とか「メンツ」とか政治的な要因が絡むことは避けられません。これが嫌でプロにならない素人(プロ以上の専門技術をもった人)もいることも事実です。

投稿2016/09/30 19:44

編集2016/10/01 00:58
HogeAnimalLover

総合スコア4830

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

###パフォーマンスと生産性にトレードオフはありません。むしろ正の相関があります。

パフォーマンスも生産性もプログラマの資質に影響されるため、トレードオフはありません。むしろ、能力の高いプログラマを雇えば、どちらもあがるので、正の相関があります。経営者の視点で言えば能力の高いプログラマを雇う・育てるべきの一点につきます。

「パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格」

そもそも、一般的によく使われている技術について、「パフォーマンスが遅くなることをわかっている技術」であることがありますでしょうか。たとえば、Webシステムであれば、 LAMP でたいがいの性能要件を満たします。逆に LAMP で難しければアセンブラで組んでも難しいです。

技術のところをアーキテクチャとかに言い換えれば納得できます。
「パフォーマンスが遅くなることをわかっていてそのアーキテクチャを採用することはプロとして失格」
というのであれば、まれにあります。システムがほとんど完成に近づいてから、

データベースの性能が出ない→
そもそも全部一つのテーブルにまとめてるのが間違い→
ESBやMQでデータベースを分割して目的ごとにシステムを再構成

みたいなストーリーはあります。このとき、ちゃんとしたアーキテクトが最初から設計していればそんなことにならなかったのにプロとして失格というのであれば理解できます。

言語処理系で性能の優劣が決定するなんてことは今の時代ほとんど無いでしょ。アセンブラで組んでもJava で組んでもせいぜい2倍くらいしか性能はかわりません。2倍で良ければ負荷分散やCPUのアップグレードを検討したほうがいいでしょう。それこそスケールアウトできるアーキテクチャのほうがよっぽど重要です。

言語処理系に前提としているような性能差がある派とない派でみごとに意見が割れてますね。その状況を見て追記します。

参考にされているベンチマークのソースコードを見ましたが、 double の加算と平方根の処理の勝負になっていて、これでアプリケーションに対する言語処理系の差を議論するのは無理があると思います。科学計算、ゲーム、ディープラーニングの場合は別ですが、そうなると、最近はGPUを呼び出したりするので、やっぱり言語は関係ないかと。

一般的なWebアプリのベンチマークなら
Web Framework Benchmarks
とかのほうが良くないですか?


参考にされてるベンチマークについて更に追記です。
ソースコードを見ましたが、 C++ 版では SIMD命令を使ってベクトル演算してます。他の言語は要素1個ずつ計算しているので、明らかに不公平です。
Java版をYeppp!とかを使って書き直してから比較すべきと思います。

投稿2016/09/30 02:48

編集2016/09/30 23:49
mit0223

総合スコア3401

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

raccy

2016/10/08 13:20

Webアプリのことを聞きたいのでは無くて、単に例として出しただけですので、深い意味はありません。参考に上げたベンチマークに不安のようですが、Webに特化しない一般的な言語比較のベンチマークがあれば、教えてください。 「能力の高いプログラマ」であれば「正の相関」であるということは、パフォーマンスが上がる方法であればあるほど生産性ががあるということでしょうか?「能力の高いプログラマ」であればトレードオフは存在しないという意味であってますでしょうか?
mit0223

2016/10/08 15:16

すみません。誇張して言ってます。他の質問でもちょっとやり過ぎた感がありまして… 主張したかったことの一つは、Web に限らず、いまどき言語処理系の性能が、というよりもcpu 含めて演算処理性能がアプリの性能に影響することは(性能問題の元凶となることは)あまりないですよねと言うことです。実際の性能問題に直面した時に、変なことを言う人が多くてついついこの手の議論になると、ムキになってしまいます。 二つ目は性能問題は演算処理性能よりも、プログラマの能力に依存する場合のほうが多いですよねということです。なので、経営者の視点から見れば、能力の高いプログラマを雇えば、性能も生産性も上がると言うことになると思います。 あくまで、年寄りの経験則ですので、気に障りましたら老害として無視してください。
guest

0

やはり出典を明らかにしないと、本当にその方が出題者さんというような意見なのかもわからないです。
特に書かれた方がどんな状況で言っているのかで随分と違いが出るはずです。

Webに限って言うと、応答時間に関していうとクライアントの基準値より遅いのはどれくらい遅いかは問題になります。ユーザーにとってもある速度から遅いかは問題になります。逆に基準値よりどれだけ早いかについての評価はほとんど意味がありません。

もちろん、いま基準値内にあるサービスが種々の条件の変化によって遅くなってしまう可能性があるので、余裕はあるべきですが、必要以上の速度に早い必要は無いと思います。

これがアクションゲームであるなら、処理速度はどこまでも速さを追求したほうがよくなるかもしれません。

また、同じものを作ると考えると、どうしても処理速度が早い環境は開発時間がかかり、バクを作り込む可能性が高くなります。処理速度が遅いのはそれを自動で行っているためだからです。


補足を受けて追記します。

ちゃんと書いてませんできたが、私ならBプランです。

その時点で想定される必要十分な条件を満たし予算を最小化すべきです。必要であれば将来の状況を要件に入れるべきです。

また、恐怖感からの対応であるなら、経験的に外す可能性が多く、恐怖感がある場合はその内容に対して誠実に検討をすべきだと思います。へたな作り込みは、現行の予算を圧迫した上に将来の変更負荷を増大させるため慎重になるべきだと思います。

また追記部分より受ける印象としては、また「本物のプログラマはPASCALを使わない」の話かという印象です。(もちろんraccyさんが書いた記事の説明からの印象です。)

パフォーマンスへのトレードオフは把握すべき内容ですが、例えば、社内向けのWebページをRoRで組んで悪いわけがないし、社員数が20倍になって動かなくなったとして、それはその前に対策すべきだったというだけで初めの選択が間違っていたという話ではないと思います。

投稿2016/09/29 23:55

編集2016/10/08 15:16
iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

差支えない範囲で出典は明示した方がいいです。
パフォーマンスが良いに越したことはありませんが、造り込む時間も限られますから、許容時間内に収められればとりあえず良しで済ませることが多いです。

DBのパフォーマンス・チューニングで顔を背けたくなるような作りの一連のプログラムを3ヶ月ほどで全部作り直して、処理時間を十分の一にしたことがあります。最初に設計・開発したメンバーにパフォーマンス・チューニングできるメンバーが一人でも参加していればここまでひどくなかったはずですが、能力は無関係に人件費の安いメンバーを頭数だけ揃えたシステムで、火消しで呼ばれることが何度もあります。

最初からまともに作っていれば、カットオーバーが2年も遅れてその間途中で入れ替えた100人以上のメンバーの人件費のほとんどが浮いたはずです。

投稿2016/09/29 23:36

Orlofsky

総合スコア16415

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

「パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格」

前半の下りが「実現不可能であることを知っていながら~」を意味するのであれば、プロフェッショナルとしての倫理的な問題があるでしょう。

そこまで強いニュアンスでなければ、工期・費用とのトレードオフや、調達可能なリソース(開発者スキルセット)との相談になるかと思います。Webシステムの場合、単なるパフォーマンスを求めるよりも、システムのスケーラビリティや継続的な更改・機能拡張にそなえた方が良いと思います。個人的には。

投稿2016/09/30 04:05

yohhoy

総合スコア6189

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

そもそもパフォーマンスって生産性を指すことがある言葉じゃないですか
それをトレードオフと考えるのは間違っているのではないでしょうか
パフォーマンスという外来語が定着した背景には性能という言葉だけでは語られない総合的な能力を表す言葉だったというのがあるのではないかと思います
経営者や購入者からするとパフォーマンスが高いシステムって良く金を生むもしくは見返りが大きいシステムですよね
でもそれって決して性能が高いシステムっていうことではない訳です

つまりは、パフォーマンスを考えるのであれば総合的な顧客の満足度を考える必要があるということです
ということでお客さんが何を望むかということを良く考えなければならないってことじゃないかと思います

投稿2016/10/08 12:23

matsu

総合スコア702

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

raccy

2016/10/08 12:59 編集

すいません、今回の質問では「パフォーマンス」を「性能」という意味だけで使ってしまいました。総合的な「効率」という意味にはならないようにしたつもりでしたが、わかりにくかったようで申し訳ないです。 「性能」の意味として捉えてくれるように、質問を編集しました。
guest

0

まず、スキルをもった人を用意できるかが重要だと思います。

投稿2016/10/06 05:52

NOTEPAD

総合スコア80

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

raccy

2016/10/08 13:03

「スキルを持った人がいればトレードオフなど存在しない」という意見でしょうか?
guest

0

場合によると思いますが、一般的なWeb系のシステムでしたらCプランでも良いのではないでしょうか。

Webに限って言うならば、複雑な画像の処理や計算といったことをしない限りは、言語間でのパフォーマンスの差はそこまで感じないはずです。

いくら早い言語で作ろうと、サーバの構成やチューニング、cssやjsで重たい処理を行う、読み込むリソースが膨大、といった理由で遅くなることは、しばしばあります。
今はマシンのスペック向上やインタプリタも最適化されていますので、Cプランで応答時間が1秒を超えることすらあまり無いです。

投稿2016/09/30 02:19

編集2016/09/30 02:25
toritoritorina

総合スコア972

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問