私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ+ JavaScript の質問用スレッド vol.110 +
JavaScript スレッド一覧へ / JavaScript とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
a = new Array(5);
for (var i = 0; i < a.length; i++)a[i]=null;
a = [];
for (var i = 0; i < a.length; i++)a[i]=null;
どっちが早くてメモリ小さいですか？
for (var i = 0; i < a.length; i++)a[i]=null;
a = [];
for (var i = 0; i < a.length; i++)a[i]=null;
どっちが早くてメモリ小さいですか？
でも一つの文字列に格納したらものすごく重くなって死にますよね
配列に一行ずつ入れるんですか？
配列に一行ずつ入れるんですか？
http://www.hp-stylelink.com/news/2013/10/20131008.php
ここに
＞ユーザーの入力に悪意のあるスクリプトが混入していた場合、
＞実行されてしまうおそれがあるので、
＞ユーザーの文字列の入力に対して、
＞evalを使用するのは避けてください
という文句がありましたが
ユーザーサイドで実行されるスクリプトが
ユーザーからの操作を気にしても仕方ないのではないでしょうか？
気にする必要があるのは
ユーザー以外が入力できる可能性のある文字列のパースではないですか？
また、deleteを使ってはならない理由もわかりません
ここに
＞ユーザーの入力に悪意のあるスクリプトが混入していた場合、
＞実行されてしまうおそれがあるので、
＞ユーザーの文字列の入力に対して、
＞evalを使用するのは避けてください
という文句がありましたが
ユーザーサイドで実行されるスクリプトが
ユーザーからの操作を気にしても仕方ないのではないでしょうか？
気にする必要があるのは
ユーザー以外が入力できる可能性のある文字列のパースではないですか？
また、deleteを使ってはならない理由もわかりません
でも10万文字目を削除するとかいう処理が
一つの文字列だと激重になるのでは
JavaScriptに限らずですが
一つの文字列だと激重になるのでは
JavaScriptに限らずですが
行単位で配列にしてもいいし
Blobから見えてる範囲だけライブロードしてもいい
あと思うじゃなくて実際に試してみな
両者こう思うの言い合いだけじゃ何も進展しないだろう
Blobから見えてる範囲だけライブロードしてもいい
あと思うじゃなくて実際に試してみな
両者こう思うの言い合いだけじゃ何も進展しないだろう
テキストフォームにfocusinした時に、全選択状態にするようにしました
デバッガで追っていると確かに全選択されるのですが、
デバッガで止めずに動かすと選択が解除されるのです
そこでsetTimeoutでfocusinから10ms後に選択するようにするようにしたら、
ちゃんと選択されるようになりました
ですが、何が選択をキャンセルしているのか分からないのが気持ち悪いです
どんな可能性がありますか？
デバッガで追っていると確かに全選択されるのですが、
デバッガで止めずに動かすと選択が解除されるのです
そこでsetTimeoutでfocusinから10ms後に選択するようにするようにしたら、
ちゃんと選択されるようになりました
ですが、何が選択をキャンセルしているのか分からないのが気持ち悪いです
どんな可能性がありますか？
＞何が
ユーザーの操作が
Chromeで試したが両方全選択にはならない
こういう挙動に頼るのはやっちゃいけない
ユーザーの操作が
Chromeで試したが両方全選択にはならない
こういう挙動に頼るのはやっちゃいけない
ありがとうございます
ユーザーの操作とはどういうことでしょうか？
ただフォーカスしただけなのにキャンセルされる意味が分かりません
ユーザーの操作とはどういうことでしょうか？
ただフォーカスしただけなのにキャンセルされる意味が分かりません
フォーカスってクリックだろ？
タブフォーカスなら両方安定にフォーカスされるよ
タブフォーカスなら両方安定にフォーカスされるよ
そうなった場合は全体がセレクトされるが
タイミングの問題でそうならないことが多いから中途半端にセレクトされてる
タイミングの問題でそうならないことが多いから中途半端にセレクトされてる
>>462
10万文字目って考えるから
重くなるって思うんじゃね？
100,000バイト目（UNICODEだとして300,000バイト目）
つまり100KB（300KB）
たったこれっぽっちのメモリコピーに
かかる時間はごくわずかでしょ？
10万文字目って考えるから
重くなるって思うんじゃね？
100,000バイト目（UNICODEだとして300,000バイト目）
つまり100KB（300KB）
たったこれっぽっちのメモリコピーに
かかる時間はごくわずかでしょ？
サイズなんて入れるもののタイプで変わってくるから
サイズ通りメモリを確保するわけじゃない
サイズ通りメモリを確保するわけじゃない
一度に巨大な領域を確保すると初期化コストがかかりすぎるってだけで
トータルではサイズ指定した方が速いのでは
トータルではサイズ指定した方が速いのでは
これを見ればV8で何が行われてるのかよく分かんだね？
http://jsperf.com/pre-allocated-arrays/22
http://jsperf.com/pre-allocated-arrays/22
Chrome 32では指定した方が速くなってるな
結局「どちらが筋がいいか」が最適化の基準になるということだろう
筋の悪い最適化は所詮一時的なもので長期的には高い確率で逆転する
結局「どちらが筋がいいか」が最適化の基準になるということだろう
筋の悪い最適化は所詮一時的なもので長期的には高い確率で逆転する
要素数を指定した方が遅くなる、っていうのは筋が悪いから
いずれ逆転する可能性は高いと思う
いずれ逆転する可能性は高いと思う
V8のFirstArray分岐点はkInitialMaxFastElementArrayで決まってる
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/objects.h#2609
だいたい100K要素までだけど変わることもある
この前は64bit環境のバグが云々で
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/objects.h?r=16324
95Kまで下がった
もしかすると今のChromeStableバージョンがこれかもしれない
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/objects.h#2609
だいたい100K要素までだけど変わることもある
この前は64bit環境のバグが云々で
http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/objects.h?r=16324
95Kまで下がった
もしかすると今のChromeStableバージョンがこれかもしれない
要素数に応じて使われ方が違うだろうから
統計を参考にするV8は
GCとかも考えてそれぞれにあった最適化してるんじゃないの？
統計を参考にするV8は
GCとかも考えてそれぞれにあった最適化してるんじゃないの？
http://stackoverflow.com/questions/6711462/chrome-thinks-99-999-is-drastically-different-than-100-000
10万未満なら実際にメモリの割当をするが、10万以上ならしない
はっきり分かんだね？
10万未満なら実際にメモリの割当をするが、10万以上ならしない
はっきり分かんだね？
>>488
他にも要素数が細かく決められていて面白い
他にも要素数が細かく決められていて面白い
あったあったこれだ
これは紛れもない真実だから参考にした方がいい
http://1000ch.net/2013/01/04/JavaScriptPerformanceTechniqueByGoogle/
これは紛れもない真実だから参考にした方がいい
http://1000ch.net/2013/01/04/JavaScriptPerformanceTechniqueByGoogle/
function Klass(){
if(Math.random<0.5){
this.x=1
this.y=2
}else{
this.y=1
this.x=2
}
}
if(Math.random<0.5){
this.x=1
this.y=2
}else{
this.y=1
this.x=2
}
}
「要素数指定しない場合と同じになる」なら分かるけど
遅くなるってのはアルゴリズムが悪いだろ
単に要素数が閾値を超えていたら指定しない場合と同じ処理すりゃいいんだから。
lengthだけは変わるけどここまで遅くなるのは道理が通らない
舐めてんのか
遅くなるってのはアルゴリズムが悪いだろ
単に要素数が閾値を超えていたら指定しない場合と同じ処理すりゃいいんだから。
lengthだけは変わるけどここまで遅くなるのは道理が通らない
舐めてんのか
>>497
おおお…
おおお…
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
JavaScript スレッド一覧へ類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.111 + (1001) - [97%] - 2013/11/4 6:00
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.120 + (1002) - [97%] - 2014/11/8 1:15
- + JavaScript の質問用スレッド vol.119 + (1002) - [97%] - 2014/10/3 15:30
- + JavaScript の質問用スレッド vol.118 + (1002) - [97%] - 2014/8/29 22:30
- + JavaScript の質問用スレッド vol.117 + (1009) - [97%] - 2014/8/5 3:30
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.116 + (1002) - [97%] - 2014/7/1 0:45
- + JavaScript の質問用スレッド vol.115 + (1001) - [97%] - 2014/5/29 16:16
- + JavaScript の質問用スレッド vol.113 + (1001) - [97%] - 2014/1/25 12:46
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.100 + (1001) - [97%] - 2012/6/13 22:46
- + JavaScript の質問用スレッド vol.140 + (1001) - [97%] - 2019/9/19 10:45
- + JavaScript の質問用スレッド vol.109 + (1001) - [95%] - 2013/10/7 13:16
- + JavaScript の質問用スレッド vol.121 + (1001) - [95%] - 2022/11/29 16:30
トップメニューへ / →のくす牧場書庫について