+ JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net

[過去ﾛｸﾞ] + JavaScript の質問用スレッド vol.126 + [転載禁止]©2ch.net (1002ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

549: Name_Not_Found [sage] 2015/11/03(火) 23:41:16.88 ID:???

getFirstLine2はcharAtを使うのならこの実装で妥当だろう。
イレギュラー対策をdo/whileにしてstring.chaAtで引っかけるというのは若干トリッキーではあるが、
これが許可されるのならこれでいい。（少なくとも速度オーバーヘッドはない）
ただしJavaScriptだと一般的にはgetFirstLine1の方が速いはずなので、これが使われることはないだろう。
(C言語ならgetFirstLine2が最速)

さてgetFirstLine1だが、先述の通り、ここはB（速度）を目指さないといけない。（存在価値がない）
記述にもこの意識は見られ、Stringオブジェクト変換を減らしている。この辺はいい。
そこで処理順なのだが、速度を目指すのだから、よくある順にショートカットにして組むことが必要になる。
つまり、-1 && -1 の「例外」を最初に見るのではなく、
20,21とかの「通常」のケースを最初に処理しないといけない。

ただし、
> ポリシー次第だと思う
これはその通りで、「最初に例外処理を行うというルール」であれば、
最初に -1 && -1 を記述しなければならず、旧コードが妥当なものになる。
ただこのケースは余りないように思う。（後述)

Math.minについては、比較演算子よりも遅く、今回は採用する理由がない。
速度を目指すコードである以上、可読性が極端に落ちない限りは速い記述を採用するべき。比較演算子は十分に分かりやすい。
この場合はindexOfの戻り値である以上、型はnumberで確定しているのだから、比較演算子で何も問題ない。
（そちらの指摘通り、「比較演算子」と「メソッド」のどちらかに統一しろというルールもあると思うが、
俺は見た目ではなく実用性を考えているので上記の理由になる。
多分そちらの「構造化プログラミング」ってのはreturnを1個にしろという話だろうけど、そういうのは俺は気にしていない。
あくまで実用性重視であり、見た目が欲しければ最初からA(getFirstLine3)を使って終わらせる。
わざわざgetFirstLine1を使うのは速度が欲しい時だけであり、中速で中途半端に整ったコードには実用性がない。)

http://peace.5ch.net/test/read.cgi/hp/1444186237/549

550: Name_Not_Found [sage] 2015/11/03(火) 23:41:52.38 ID:???

さてイレギュラー対策だが、多分（ここら辺は本職から聞くべきだが）
α. 安全重視、全箇所でチェック。
β 速度重視、最初にチェック、以降は「型」までは確定、値については保証無し。
のどちらかで組むのだと思われる。
ポリシーαで、どういう状態でも安全性を明示するために「最初に例外処理」のルールなら旧コードが妥当になるが、
実用的にこれはないように思われる。
普通の仕様としては、「イレギュラーなら例外、それ以外は正しく処理」であり、関数内の記述順まで規定される必要はない。
記述順を規定する＝ソースコードを見てデバッグするということだが、その場合は普通は「例外を投げずに自分で処理しろ」となるからだ。
またJavaScriptの場合はgetFirstLine3のように「暗黙的なイレギュラー対策」が出来ることも多く、（確認していないが)
「明示的なイレギュラー対策を最初に行え」というルールだと色々無理が生じてしまう。
だから、お行儀がいいとは言えないが、
現実的にはgetFirstLine2のようなトリッキーなイレギュラー対策もありってことになっている場合が多いのではないかと推測される。
(ソースコードに明示的に書いてあるかどうかではなく、実際に動くかどうかが仕様）

ただ、それ以前に、「どんな型でもちゃんと処理しろ」というのはやはり負担が大きく、どこかしらでバグるだろうから、
普通はポリシーβで、getFirstLineが呼ばれる時はstringが渡されるところまでは確定していると思う。
この場合は「正しく処理しろ」という仕様だろうから、-1 && -1 の処理は後回しでいい。（最初に書くことを強制されない）

俺の場合はポリシーβで、基本的に最初は全部Aで書いて、問題がある場合のみBに差し替えるという方法を採っている。
したがって中速コードは不要で、各関数に於ける例外処理も基本的に無しだ。だからこんな感じになる。
他のポリシーと記述スタイルなら他の考え方もありうるとは思うが、
上記のように現実的にはαは効率が悪くて無理だと思うし、
速度についてもソースから直接予想できるケースばかりでもないので、
結果的に本職も俺と同様のポリシーになっているのではないかとは思っている。

http://peace.5ch.net/test/read.cgi/hp/1444186237/550

558: 547 [] 2015/11/04(水) 01:32:27.89 ID:pUq54Vxq

>>550
> ただ、それ以前に、「どんな型でもちゃんと処理しろ」というのはやはり負担が大きく、どこかしらでバグるだろうから、
そんなことはない
どんな型でも安全に処理すべきだし、私のポリシーは「1: 安全、2: 速度」だ
ECMAScript は型が緩いといわれるが、それは内部的に型変換して処理しているからだ
ほとんどの演算子、関数は内部的に始めの処理でキャスト(型変換)している
従って、始めの処理で引数をキャストしておけば「どんな型でも適切に処理」することは難しくない
ここで回答する時には「例外処理ぐらいは自分でやってくれ」のスタンスで意識的に省略することがあるが、>>537の指摘は妥当なものだ
例えば、RegExp.prototype.exec は第一引数を ToString (String型に変換) するのでどんな型でも適切に処理できる
http://www.ecma-international.org/ecma-262/6.0/#sec-regexp.prototype.exec
>>531は String.prototype.match を使用しているが、これは String 型を引数に持たない場合に適切に処理できないので妥当ではない
ES 仕様で内部的に型変換してくれるのならそれを利用すべきだ
ネイティブ関数の内部処理でキャストする方が String() でキャストするよりも速度面で有利だからだ

しかし、速度重視のスタンスの割には getFirstLine1 で i1 === -1 の比較回数に触れられていないのが意外だ
私としては速度的にまだ満足できるレベルではなかったので、あなたが「最良のアルゴリズム」を出してくれることを期待していたのだが
getFirstLine1 は i1 の比較が最大で3回実行されるというのが無駄だと思っている
var has1 = i1 !== -1; のように結果をキャッシュさせる事も対策の一つとして考えられるが、比較回数を減らすのが重要だろう
http://jsfiddle.net/cau4mx8d/4/

ECMAScript はスコープチェーンで変数を参照するのでグローバル変数は基本的に遅い
その為、String() を使うときにはクロージャに閉じ込める等してスコープ走査回数を抑える実装にする事がある
ここでは getFirstLine1 はグローバル関数なので気にする必要がないが、実際に運用では気をつけるべきだろう
また、String() ではなく、arg + '' で型変換する方法もあるが、この方法は ToString() とは違うので基本使わない

http://peace.5ch.net/test/read.cgi/hp/1444186237/558

562: Name_Not_Found [sage] 2015/11/04(水) 02:54:58.75 ID:???

> 空文字を引数にとる場合、do-while では速度上で問題が出るだろう
> getFirstLine1 に気が向いていたので妥協したが、while 文にした方が速いだろう
何故だ？cau4mx8d/3/とcau4mx8d/4/では速度差は出ないはずだが。（中身は同じだ）
多分ただの勘違いだと思うが、do/whileもショートカット論理で動く。

> ES 仕様で内部的に型変換してくれるのならそれを利用すべきだ
もちろんその通りだが、バグを少なくするコツは「簡単にすること」だ。
だから、単純に「どんな型が来るか分かりません」よりも「必ずstring型が来ます」の方がバグらない。
ポリシーとしては、多分、
α：各関数で型チェック、つまり各関数は複雑になりますが、個々で安全を保証します。
β：入力先頭で型チェック、つまり各関数は型決めうちでシンプル、ただし入力の最初に必ず型保証を入れる必要があります。
のどちらかになる。JavaScriptの場合はどこで入力しているか見やすいので、多分βの方が全体的に簡単になると見ている。
ただここら辺は本職に確認した方がいい。

> あなたが「最良のアルゴリズム」を出してくれることを期待していたのだが
俺は俺ツエーするために書いているわけではないからね。それは君が君自身のためにやるべき事だ。
ただ、速くしたいだけなら他にも策はあって、
例えば今回はCRLFまたはLFなのだから、indexOf('\n')ではなく indexOf('\r')-1をチェックすればいい。
-1の比較回数を減らすのは実は余り効かない。それはループではないから。（関数で1回だから）
ただ、それをしたいのならすればいいし、そういうところにはこだわるべきだと思う。
とはいえ、cau4mx8d/4/のコードだと i1=-1, i2=-1の場合、2つ目のsliceに当たってしまうぞ。

> String() を使うときにはクロージャに閉じ込める等してスコープ走査回数を抑える実装にする事がある
これな、以前は確かにこの通りだったが結局最適化で何とかなったらしく、String()はイラネーみたいな記事もあって、
実際のところこちらでも大して変わらなかった記憶がある。
（以前の実装用に最適化したJSはバッドプラクティスになった！みたいな書き方だったが、俺が試した限り、遅くもなかった）

http://peace.5ch.net/test/read.cgi/hp/1444186237/562

上下前次 1-新書関写板覧索設栞歴

あと 438 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.353s*