JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net (766ﾚｽ)
JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1449440793/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
109: デフォルトの名無しさん [sage] 2016/05/10(火) 23:06:42.46 ID:vhPcYSkB > 低レベル系のAPI 上の話ともリンクするが、ブラウザはお手軽さが最も重要なのであって、 ゴリゴリ書いて性能を出すのには不向きだし、流行らないと思うぞ。 結局のところ、専用ネイティブアプリには実行効率では勝てないのだから、必要なら開発される。 そこまでの必要/需要が無ければブラウザアプリのままでいけることになる。 ただ一つ思うのは、CPUとI/Oを分離し、非同期で書くことを強制するのは、実はかなり効いている。 体感、思っているよりだいぶ速いんだよね。 他言語だと普通に同期で書くし、描画でもそのまま記述する。（分離して書く習慣が無い） これら遅い部分を明示的に分離し記述することが半強制されている結果、 結果的にCPU稼働率の高い「割と速い」コードが出来上がることとなっている。 だからちゃんと書いたJavaScriptは十分速いし、 それ以上の速度を要求するのならC/C++で書き直すしかない。(V8がC比5倍程度と十分速い為） どんなJavaScriptでも最後にトランスパイルすれば速くなるというのなら、それはJIT側に含まれるべきだし、 何らかの記述制限をつけて「ちょっと速いJavaScript」を目指すものは、多分需要が無い。 （本来そこにはC比3倍程度というJavaアプレットがいたはずだが、完全に死んでるし） http://mevius.5ch.net/test/read.cgi/tech/1449440793/109
110: デフォルトの名無しさん [sage] 2016/05/11(水) 07:45:48.20 ID:XhqmdNgU >>109 考え方が全く違う。低レベルAPIは、高レベルAPIを作るために必要なの。 高レベルAPIを標準仕様として策定してたら互換性などを強く考慮する必要があり、 メジャーブラウザが一通り実装して使えるようになるまで極めて時間が掛かる。 そしてその時に本当に必要とされるものに出来なかったという失敗も数多くしてきた。 実装にも時間が掛かるが、古いAPIを削除するにはそれ以上の時間がかかってしまう。 でも低レベルAPIを提供するようにすれば、ライブラリやポリフィル程度の気軽さと速度で その時代に必要とされる高レベルAPIが作られていくようになるし、 そこで持て囃されデファクトを築いた仕様を改めて標準に持って来ればいい。 ポリフィルだらけになるということさえなんとかすれば、他の様々な問題が解決される。 それが低レベルAPIの道入。「Extensible Web Manifesto」だよ。 >>109 また、何をもってちゃんと書くと言っているのかわからない。 結局スクリプト言語であるJSの大部分のコストかかる場所は大抵DOMなんかの外部APIを叩いた部分だからね。 でもそうでないゲーム思考エンジンなどを作ったりするけど、「ちゃんと書けば」 単純演算系ロジックのパフォーマンスが1/5倍なんて最悪の見積もりだよ。 1/5くらいのケースもあるけど、10％程度しか分からないケースもあり、アベレージで大体1/2位になる。 まだSIMDやらパラレルやらの最適化が完了してないのでそこが大きく絡むともう1/2くらいにはなるが、 1/5は最悪中の最悪ケース。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/110
284: デフォルトの名無しさん [sage] 2016/06/30(木) 01:34:38.72 ID:YtNZP2Mq ちなみに、当面の問題は解決した。 実はもっさりというよりはカクカクに近かったのだが、原因はキャッシュによるHDDアクセスの過剰だった。 ヘッダに cache-control: no-store を追加したところ、完全に治った。 ただそれでも(program)が70-90%であることには変わりないのだが、 スクレイピング中でも(idle)は80%以上なので、キビキビ感はある。 前にも書いたが、(>>109) CPUだけで動く部分は実は相当速くて、UIが主なJavaScriptではCPUを使い切ることはないのかもしれない。 俺の場合はスクレイピングが律速過程なので、サーバの速度が上がらない限りここで頭打ちだ。 数値計算のように完全にCPUだけで回るのなら限界が見えるが、そういう用途はないし。 遅延描画は制御がやや面倒だが、実現してしまえばDOMは1画面分しか扱う必要がなく、一瞬で処理される。 俺のアプリに関して言えば、階層スクレイピングを行っているので、 下位階層を参照する時は更新されていることが確定している。 だから no-store で全く問題ないし、あと5倍の余裕があるので、残るは美学的問題だけになった。 ここを修正するかはしばらく様子見になる。 情報をくれた人はありがとう。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/284
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.035s