のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,695,971人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

元スレ+ JavaScript の質問用スレッド vol.109 +

JavaScript覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

251 = :

http://jsperf.com/call-apply-segu

applyよりcallがパフォーマンス高いのは何故ですか？
差がありすぎでは？

252 = :

>>251
callとapplyの実行時間の差より配列作る時間の方が長かったりしない？
別に同じ意味のプログラムである必要はないんだから、callも配列作って渡してみれば？

253 = :

なるほど
確かに配列の作成はコストが高そうです
ありがとうございました

254 = :

http://jsperf.com/apply-vs-call3

条件を揃えて比較しましたがやはりcallの方が圧倒的に速いですね

255 = :

arrayが参照されないから最適化されちゃってるんじゃないの？
両方とも配列渡しちゃえよ

257 = :

配列を渡したらそれはそれで両者の条件が変わりますよ
というかそこが本質でないのは明らかです
この大きな速度差はどこから来ているのか？という問題が主題です

259 = :

>>242
何言ってんだこいつは

260 = :

>>257
大きな速度差はfirefoxだけだから、たぶん配列に関する最適化の差だな

261 = :

配列か否かだけでこんなに差が出るわけがないと思いますが。
関数オブジェクト自体を作り直してるんじゃないかという勢いです
bindは関数オブジェクトを作ると聞いた記憶があるので
内部でbindしてるのかもしれませんね

262 = :

遅いapplyを使ってるapply.pushより遅いconcatって・・ﾌﾟｰｸｽｸｽ

263 = :

>>261
大きな差があるのはfirefoxだけなのは確認した？
firefoxのcallのほうは配列に関する処理をまったくやってない可能性がある
bindは全く関係無いよ

264 = :

二倍近い差は充分に大きな差ですが・・
bindは全く関係ないとか、知らないのに何で言っちゃうんですか？ﾌﾟｰｸｽｸｽ

265 = :

>>262
本来用途の違うものを比較してﾌﾟｰｸｽｸｽって・・ﾌﾟｰｸｽｸｽ

266 = :

>>261
applyが内部でbind使うの？callは使わないの？

267 = :

firefoxで大差、chromeで2倍弱、IEで結果がひっくり返るってことは
たぶんJSの最適化関係なんだろうなｗ
firefoxのこれはたぶん無茶なインチキくさい最適化してるｗ

268 = :

http://stackoverflow.com/questions/15455009/js-call-apply-vs-bind

bindが内部でapplyを使っているようですね
bindの遅さもapplyの遅さに起因すると

269 = :

引数が動的に与えられるとキャッシュが効かないとかかなぁ

270 = :

IEではapplyの方が早いのを全く無視して話をすすめるのか

272 = :

http://jsperf.com/call-apply-segu

これ見るとIEでもcallの方が速いけど？
普通に考えてcallの方が速くなる方が自然だし、それが逆になるのは実装がおかしい
そして不自然な実装に最適化することは長期的に考えて愚か

273 = :

>>268
> bindが内部でapplyを使っているようですね

どこにそんな記述がある？
そもそも bind は function オブジェクトを返すもので、
bind 呼び出し時は関数は実行されないから、apply の実行速度と
全く関係ないと思うけど。

275 = :

>>272
そっちだとapply側だけ配列確保してるからIEもcallが早くて他のブラウザと同じ傾向になる
http://jsperf.com/call-apply-segu

こっちは両方とも配列確保してるけど、
firefoxやchromeはcall側の配列に関する処理を省いちゃうので上のと同じ傾向になる
素直はIEはまじめに両方とも配列確保しちゃうので差がなくなっちゃった(実際には差が反転)のではないかな
http://jsperf.com/call-apply-segu

276 = :

ああ、ごめんURLまちがった下はこっち
http://jsperf.com/apply-vs-call3

277 = :

普通に考えるとapplyの方が素に近い処理じゃないか？
可変長の引数の取り扱いより、配列1個受け取ったほうが処理は楽だろ？

278 = :

なんでやねんw
インターフェイスが確定されないんだからパフォーマンス落ちるのが当然

279 = :

applyよりもcallが速い理由を考えるんじゃなくて
applyは遅くない！と何故か主張しだすアホはなんなんだw

280 = :

呼び出しより配列確保の影響の方が大きいというのは
わりと面白い推測だと思うけど
>>275でIEだけ傾向が変わってるし

281 = :

>>279
あんたは>>251なの？

282 = :

VB2012PＲＯのアプリケーション作成でjsを用いてるのですが、なぜか画像が表示されません()

<img src="C:\Users\User\Documents\Visual Studio 2012\Projects\App2\App2\images\BOfcow-CAAE48Nz.jpg large.jpg" />
この文のどこに問題があるのでしょうか？

284 = :

>>282
画像はあきらめてCanvasで自己解決しました

286 = :

いいえ

287 = :

どうやるのが一番いいですか？

288 = :

appendでしょうね

289 = :

最適化のためにローカル変数に代入しまくるとか
オブジェクトのループ書くためにObject.keys書きまくるとか面倒くさくなってきました
coffee scriptか？とも思うけどcoffee scriptにした後にcoffee scriptが廃れたら・・とか不安です
どうしたらいいですか

291 = :

オブジェクトのキーの列挙に最適化なんて要らん
ローコル変数のキャッシュも同じく
そういう細かい所はエンジンの責任

あとはパレードの法則に従えば限られてくる
だがその前にアルゴリズムを疑え
最適化気にする奴が書くコードは質が悪い
最適化っていうのは良いコードを書いて最後にちょこちょこっとするものだ

292 = :

オブジェクトのループと言う時点で結構怪しい。

293 = :

if (hoge) a =1 else b=1;
だとエラーになり
if (hoge) a =1;else b=1;
だとエラーにならないのは何故ですか？

294 = :

パフォーマンスを気にしないで書けるほどJavaScriptの最適化が進んでいるとは思いませんが。
むろん理想的にはそうです。

295 = :

>>4 にあるべき各種仕様■各種仕様 (http://fiddle.jshell.net/vSqKr/33/show/#Link も参照 )
◆ Standard ECMA-262
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/ （ECMAScript 3 和訳）
http://es5.github.io/ （ECMAScript 5.1 有志HTML版）
http://people.mozilla.org/~jorendorff/es6-draft.html （ECMAScript 6 有志HTML版）
http://kangax.github.io/es5-compat-table/ （ECMAScript 5 compatibility table）
http://kangax.github.io/es5-compat-table/es6/ （ECMAScript 6 compatibility table）
◆ HTML Standard (HTML5)
http://www.whatwg.org/specs/web-apps/current-work/multipage/
http://momdo.s35.xrea.com/web-html-test/spec/WD-html51-20130528/Overview.html (HTML5.1 和訳)
http://www.hcn.zaq.ne.jp/___/WEB/WebStorage-ja.html（Web Storage 和訳）
◆ Document Object Model (DOM) / CSS Object Model (CSSOM)
http://www.hcn.zaq.ne.jp/___/WEB/DOM4-ja.html （DOM Standard (DOM4) 和訳）
http://www.w3.org/TR/DOM-Level-3-Events/ （DOM3 Events）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-ja.html （CSSOM 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/cssom-view-ja.html （CSSOM View Module 和訳）
◆ その他のWeb関連仕様
http://domparsing.spec.whatwg.org/ （DOM Parsing and Serialization - innerHTML等）
http://www.hcn.zaq.ne.jp/___/WEB/XHR-ja.html （XMLHttpRequest 和訳）
http://www.hcn.zaq.ne.jp/___/WEB/File_API-ja.html （File API 和訳）
http://notifications.spec.whatwg.org/ （Notifications API）
http://www.whatwg.org/specs/ （WHATWGの仕様一覧）
◆ MDN (Netscape/Mozilla)
http://developer.mozilla.org/ja/docs
◆ JavaScript Garden (ja)
http://bonsaiden.github.com/JavaScript-Garden/ja/
◆ JSON (JavaScript Object Notation)
http://www.json.org/json-ja.html
◆ MSDN Library
http://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://msdn.microsoft.com/ja-jp/library/cc427807.aspx (JScript)
http://msdn.microsoft.com/ja-jp/library/cc409712.aspx (DHTML)

296 = :

>>293
ここを熟読するべし。熟読しても分からないならその時は説明してもいいよ。
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/7_Lexical_Conventions.html#section-7.9

297 = :

ありがとうございます
早速読んでみました
ifステートメントのconsequentがブロックステートメントでない時は
ステートメントの終わりが分からないということだと思います
しかしelseが出てきたならその時点でステートメントの終わりなのは明らかです
現に他の言語では;を必要としないものも多くあります
何故JSでは;を必要とするのでしょうか？

298 = :

>>294
君が知らないだけだよ

299 = :

特殊なケースを覗いてわざわざ悪い書き方をしてないのに遅いんならエンジンの責任。
逆に最適化ノウハウはエンジンごとに違うから多用するものではない。
結局、「「素直」」に書くってのが一番大事。素直にね。
苦しんで書いたコードとかメンテの面でも良くない。

300 = :

>>294
パフォーマンスを全く気にしないで良いなんて言ってないがな
パレートの法則でggr


←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド

トップメニューへ / →のくす牧場書庫について