for文よりwhile文の方が速い
■ このスレッドは過去ログ倉庫に格納されています
>>3
同じことやるならwhile文の方が高速だけど forとwhileの速さなんて誰も気にせんだろ
そういうのはどうせCPUパワーなんかであっさり解決しちゃう話だしな
分かりやすい方を優先で書けばいいだけ >>6
頭悪そう
速さ気にするのなんた機械学習とかに決まってんじゃん
かなり差でるよ なんの言語のどのforだ
foreach系なら処理系によっては型チェック入ったりポインタコピーのコストでwhileの方が早くなることもあるだろうが
古典的なforを低レイヤー言語で使うなら変わらないんじゃないか >>7
機械学習って時間かかるところはライブラリ使ってやるもんだろ
それ使ってるだけのユーザー側でforだのwhileだのがクリティカルになるとは思えんのだが
まさかライブラリの開発者かなんかやってんの? 言語によってはインクリメントもインクリメント演算子使うより普通に代入した方が速かったりする
インクリメント演算子使うにしても前方に書いた方が速かったりする言語もある
日頃から実測テストする事を習慣づけてどれが速いか分かった上で統一してコーディングすると高速なプログラムが書ける 条件式や変数の初期化が入るのでwhileの方が速いのは当たり前だけど現代のマシンパワーでは本当に誤差レベルでしかないので考えるだけ無駄
llvm噛ませてる言語の場合同じ処理なら最適化されてほとんど同じ処理になる >>11
言語や環境によるけど25%程度違ってくる
制御のインクリメント等も合わせればさらに違ってくるので事前に実測を経てコーディング規則を決めるか否かでかなりの差が生まれる >>13
25%も変わるんかいな
でもそれどうせループ処理の中身ではもっと重たい処理してるんでしょ?
その重い処理も含めて考えてループ処理全体ではforとwhileの違いで何%変わるの? 誤差とか言っている人は多分大規模なプログラムやユーザ入力待ちなど他に大きな待ちがあって処理速度がシビアに影響しないプログラムしか書いたことないのだと思う >>15
例えばだけどループ処理の中身で10倍重たい処理が走ってれば
forとwhileの違いはたかが2.5%にしかならんってことでしょ 最近のコンピュータは強いからなー
プログラミングを学ぶ大多数の人間は意識しなくてもいい
言語機能による誤差よりもIOとかのほうが速度にクリティカルに速度に響く
foreachやmapやfilterを使うと明らかに速度は遅くなるがそれよりも可読性の低下による開発速度の低下のほうが後々響くので構文による速度差とか考えん >>21
だよね
よっぽど特殊なケースではforとwhileの違いにこだわるような場面もあるのかもしれんけど
一般的に言えばやっぱりforとwhileの速度の違いなんて気にしないで分かりやすい方を使えばいいって結論は変わらんなあ >>20
その説明がループ処理が遅くていい理由になるってどう言う理屈だ?
あとその重い処理とやらにもループ文は使われる訳ですべてのループに遅い方法を採用するのと速い方法を採用するかでかなり変わってくる話だよ >>23
可読性を重視するって理屈だよ
>>21 さんが言ってることに俺も賛成 >>21
フロントエンドの開発はユーザの入力待ち等生じるのと可読性重視で作るが速度が必要となるアルゴリズムやモジュールでは普通に最適化するよ >>24
フロントエンド寄りのプログラミングしかしたことないのだろうね >>27
JSならジェネレーターを使ったほうがいいんじゃないか? >>26
実際アセンブリで出力して処理を最適化する部分もあるよ whileはブランチ命令で早い
forはcmpしてjmpで遅い さすがに1からアセンブリで書く事は組み込みとかの時しか最近はしないが >>28
フロントエンドかバックエンドかはあんまり関係ないと思う
最近はバックエンドでも処理速度が遅い言語が選ばれたりも普通にするしね
速度が必要な処理はサクッとライブラリ使って解決すればいいしね whileは最悪終わる
これでクライアントのgcp3万溶かして怒られた >>30
アセンブリレベルの最適化はゲーム開発やカーネルの中でも限られた人しかやらないね
組み込みOSや機械学習やらのライブラリなんかはアセンブリレベルの最適化はする打ろうけど俺みたいなWeb開発者が知るところではないねー >>34
俺はlambdaで20万溶かしたから誤差 >>35
そうなんだよね
そういう意味では >>1の
「でもお前らはfor文使うんでしょ?」
って問いに対しては
「うん。その通りだよ。ま、可読性しだいだけどね」
としか答えられないんだよね 俺は専らgotoとfor文しかない言語を触ってるので関係ないんだけど >>33
標準や他者が作ったライブラリの組み合わせとそれを呼び出す簡単な処理で済むプログラムなら可読性重視で良いと思うよ >>40
世の中のほとんどのプログラマーはそれに当てはまるんだよね >>35
まぁそうだけど最近はWebもリッチになり過ぎて安い低スペ端末の奴の表示速度改善でjsも最適化は必要だよ
最適化がし難いスクリプトこそ記述差による速度の違いがとても大きい
グーグルとかのスクリプトもかなり最適化してある
どっちの記述の方が速いかまとめてあるページを確認してからそれを意識してプログラミングするだけでかなり変わるよ
管理しやすさを考えて全体は可読性重視で作って処理が特に重い部分だけでも最適化したものもにすると良いよ >>42
基本的に最低限の速度は必要だがどちらかと言うとどのライブラリでどのコンポーネントをどのように使うかが重要であって記述での最適化はあまり聞かないね
そもそもうちはそんな最適化せずともスピードインサイトで95以上安定して出してる 複雑なGUIとレンダリングを必要とする重いアプリケーションならLPやダッシュボードは一般的な構成で作って思い部分はWasmで済ませるね
そういう部分は読み込みが1秒以上かかってもユーザは待ってくれるしね コンパイラがうまくやってくれるから、どっちで書いても変わらないんじゃないの?
(素人の発言で根拠はないけど) GoとJava、JS(TS)を使ってるけどJavaとJSはfor, whileで同じ処理をさせればほぼ同じ時間しかかからないね 例えばswitch文ってifで二分探索するコードに書き換えられたりするし、forとwhileも同じように最適化されるだろ
速度が計測できるレベルで変化するゴミ言語なんて使うな まあecmaはイカした書き方できるだけで速度は遅いしなあ JSはそんじょそこらの言語に比べたらずば抜けて速いよ ■ このスレッドは過去ログ倉庫に格納されています