15/06/30 20:22:23.88 .net
CPUレベルで考えたそれこそFirefoxのようなシングルプロセス環境だと、
コンテキストスイッチが発生しない限りで別サイトのコードを巻き込んで最適化が発生する余地もある。
ベンチマークも信頼できなくなる。
901:Name_Not_Found
15/06/30 20:48:25.16 .net
複数のブラウザと異なるバージョンのブラウザを用意して一つ一つ検証するのが面倒だから仕様上、速くなることがわかっているコードは積極的に使うようにしてる
ブラウザがアップデートされる度に検証し直すのは面倒くさくてかなわん
902:Name_Not_Found
15/06/30 21:24:24.42 .net
そういう場面が存在することは分かるが、
少なくとも上の質問はそういうクリティカルな物ではないだろう。
ゲームとかで本当にデータアクセスを高速化しようと思ったら、
最終的に変数やオブジェクトを極力使わずasm.jsのようにArrayBufferをメモリに見立てて
903:利用する形になる。 そういう段階まで行けば確かにエンジンのバージョンによる様々な最適化のかかり具合も重要になってくる。 まあswitch vs if-else程度がギリギリ一般的にどちらがどういう時に高速かを調べられる限界だが。
904:Name_Not_Found
15/07/01 00:03:00.64 .net
質問です
CSSファイル内にjavascriptの記述を書きたい場合、方法ありますか？
905:Name_Not_Found
15/07/01 00:05:35.22 .net
ないし、やったらだめ
906:Name_Not_Found
15/07/01 00:18:57.86 .net
>>889
そういう案もあったが今はCSSで定義した変数をJSからオーバーラップする方向性で進んでる
URLﾘﾝｸ(dev.w3.org)
907:Name_Not_Found
15/07/01 08:25:09.97 .net
lodashの3.10がでてるね。
URLﾘﾝｸ(lodash.com)
908:Name_Not_Found
15/07/01 10:22:05.63 .net
この頻度で更新されるたびに話題にされたらたまったもんじゃないな
URLﾘﾝｸ(github.com)
909:Name_Not_Found
15/07/01 14:26:16.50 .net
lodashの最大の欠点はlodash（_）であるということ。
本来はES7のAbstract Referencesとライブラリのインポートでしたいことである。
910:Name_Not_Found
15/07/01 19:09:52.00 .net
java scriptファイルってwebサーバーに置いたら中身丸見えですよね。
プログラムの中身を盗まれないようにする対策って有りますか？難読化とか出来るのかな？
911:Name_Not_Found
15/07/01 20:05:36.62 .net
サーバサイドで処理しろよ
jsにこだわる必要もない
912:Name_Not_Found
15/07/01 21:11:58.74 .net
>>896
忍者HPの無料サーバーで自作のJSのアプリ作っているのですが、
サーバーサイドっていうのは、この忍者HPでも可能でしょうか？
たぶんダメですよね。
913:Name_Not_Found
15/07/01 21:30:19.30 .net
駄目です
914:Name_Not_Found
15/07/01 21:36:29.37 .net
>>894
> 本来はES7のAbstract Referencesとライブラリのインポートでしたいことである。
まったくもってその通り。
なんでさっさと標準化してしまわないのか？
仕様なんて誰が考えても大差ないようなものなんだから、
github上で一関数ごとにIssue作ってささっと仕様を決めてしまえば、
一ヶ月程度でできあがるはずだろう。
ES7の問題点は仕様が固まるまでに数年もの時間がかかるってことだ
915:Name_Not_Found
15/07/01 21:58:30.48 .net
>>898
やっぱりダメですよね。
無料サーバーでサーバーサイド出来るなんて無いですよね。残念。
916:Name_Not_Found
15/07/01 23:58:17.72 .net
>>895
昔どっかのサイトがjsをわざわざエンティティ化しているの見たことあるけど、
どうせすぐ変換できるから無駄。
Googleのソースみたいに圧縮すれば読む気は失せるけど
917:Name_Not_Found
15/07/02 00:34:35.96 .net
>>901
エンティティ化って何ですか？
918:Name_Not_Found
15/07/02 14:59:47.32 .net
圧縮してあっても殆ど変数名の短縮で
メソッド名とかは割りかし残るから慣れればさほど問題ない
919:Name_Not_Found
15/07/02 23:46:53.92 .net
慣れちゃったのか…
920:Name_Not_Found
15/07/03 09:31:47.36 .net
>>900
いたるところにある
921:Name_Not_Found
15/07/03 12:39:44.91 .net
コード整形ツールを使えばインデント整形できるからな
変数名の短縮は読みづらくなるが、読めなくはない(必要であれば読む)
922:Name_Not_Found
15/07/07 10:44:19.38 .net
スクリプト専門スレなのにすいません。
301リダイレクトで質問なのですが、他に目ぼしいスレがなくて、ここで質問させてください。
トップページは
URLﾘﾝｸ(old-site.com)
を
URLﾘﾝｸ(new-site.com)
に301リダイレクトをする方法は分かったけど、例えば旧サイトでcategory1にあった物を新サイトで、サイトURL移転と同時にドメイン以下の名称を変えて301で一気に飛ばせないのかな？
こんな感じ↓
URLﾘﾝｸ(old-site.com)
を
URLﾘﾝｸ(new-site.com)
教えてくれた人にアマゾンギフト券（e-mail)1,000円分を差し上げます。
アマゾンに登録してある事と、先着１名なので、２人目以降はすいません。
このメールに下さい
riengl@00mails.com
923:Name_Not_Found
15/07/07 11:43:23.38 qlgurl5N.net
昨今のブラウザだと循環参照してもリークしないの？
前スレみると決着ついてないんだけど
924:Name_Not_Found
15/07/07 11:45:42.12 7Cb6g2mZ.net
JavaScriptも使って以下のような仕様のページを作りたいです。
①ユーザーがページに来ると、モーダルウィンドウAが出る。
②モーダルウィンドウA上のボタンを押すとウインドウが消え、音楽がループで流れ始める。同時にカウントがはじまる。
③ページ上のボタンを押すと、流れていた音楽が消え、別の短い音楽（チャイム音）が一度流れ、カウントが止まり、モーダルウィンドウBが表示される。
④モーダルウィンドウB上のボタンを押すと、カウントした秒数とそのページのURLの文字列をふくむツイートができる。
このような仕様です。
HTMLとCSSでデザインはできようになったので、今度はJavaScriptを勉強してこのような事ができるページを1枚つくって公開するつもりです。プログラムの学習は初めてではないです。
JavaScriptをひと通りざっと勉強してから作業に入るつもりですが、特にどの部分を勉強すればこのようなページを作れるか、簡単なヒント等をもらえたら嬉しいです。
よろしくお願いします。
925:Name_Not_Found
15/07/07 11:56:42.69 .net
>>909
ウインドウの出し方はいろんな方法が有るのでその辺から試せば？
926:Name_Not_Found
15/07/07 14:01:35.84 7Cb6g2mZ.net
>>910
レスありがとうございます。
Bootstrapを利用するのでモーダルウィンドウはそれを利用するつもりでいますが、
他のウィンドウの出し方も試して検討してみます。
927:Name_Not_Found
15/07/07 20:54:08.81 .net
>>909
それはどこまで行っても「物による」から決着はつかない。
一応ネイティブCGシステムと-JSシステム間のバインディングや、
弱参照ハックによりレガシーなDOM API周りではリークは無くなっているが、
新しいAPIが出る度に例えばAudioBufferがリークしたりというようなことがままある。
928:Name_Not_Found
15/07/07 20:54:35.98 .net
×909
○908
929:Name_Not_Found
15/07/07 22:39:47.08 .net
>>911
> Bootstrapを利用するので
死ね。ここはライブラリの話題は禁止だといっただろ
930:Name_Not_Found
15/07/07 22:41:30.72 .net
>>908
> 昨今のブラウザだと循環参照してもリークしないの？
jQueryを使っている限り、昔のブラウザも含めて問題無いという結論だったはず
931:Name_Not_Found
15/07/07 22:42:25.57 .net
>>914
と童貞がほざいてます。
932:Name_Not_Found
15/07/07 22:54:07.87 .net
angularjs.org 1.4.2リリース
URLﾘﾝｸ(angularjs.org)
933:Name_Not_Found
15/07/08 06:26:38.23 S3u9jPpK.net
>>912
なるほど
メモリ効率的にも使わないほうがいいみたいですね
>>915
jqueryは毎回nullぶち込んでるから当たり前じゃ？
934:Name_Not_Found
15/07/08 18:08:05.18 e8Mh7Wfi.net
>>914
たかがCSSフレームワークに何いってんだこの気違い童貞
935:Name_Not_Found
15/07/08 22:31:28.44 .net
>>918
nullを入れてるからじゃなくて（別の理由で入れている所はもちろんあるが）
クロージャーを使った部分で JavaScriptの外の世界との循環参照にならないように
間に一層かまして、断ち切ってるからだよ。
つまりDOM（JavaScriptの外）とクロージャー（JavaScript）が循環参照にならないように
DOM（JavaScript）とjQuery（DOMの参照にクロージャー使っていない）＝問題ない
jQuery（JavaScript）とクロージャー（JavaScript）＝問題ない
このようにjQueryが問題になる循環参照を断ち切ってる。
936:Name_Not_Found
15/07/08 22:32:05.44 .net
ここってCSSフレームワークの話題オッケーなんですね。
937:Name_Not_Found
15/07/08 22:38:02.17 .net
オッケーですよ
回答する人がいるかは分かりませんが
938:Name_Not_Found
15/07/09 00:37:16.24 .net
>>920
jQueryもJavaScriptの世界なんだが……
939:Name_Not_Found
15/07/09 00:41:54.13 .net
>>923
はい。だからjQueryは「安全な方法」で実装しているから
問題ないのです。
940:Name_Not_Found
15/07/09 00:45:14.38 .net
なぜ常に安全とわかるのですか？
941:Name_Not_Found
15/07/09 00:46:20.77 .net
>>921
>>1の1行目を読めばおっけーではない事は明らかだけどな
942:Name_Not_Found
15/07/09 01:02:12.48 .net
>>925
横から口出すが、jQueryの循環参照対策は過去ログ参照
ｽﾚﾘﾝｸ(hp板:550-番)
明らかにスレ違いの話題だから以降はライブラリスレでやってくれ
ｽﾚﾘﾝｸ(hp板)
943:Name_Not_Found
15/07/09 01:16:05.60 .net
>>921
単語が出ただけでOKだと信じる短絡的バカ
944:Name_Not_Found
15/07/09 01:25:10.09 .net
>>921は>>919の間抜けな回答をあぶりだす為に答えのわかった質問してるんだろう
945:Name_Not_Found
15/07/09 01:31:12.85 .net
こりゃ次スレも禁止でケテーイだね
946:Name_Not_Found
15/07/09 01:33:34.71 .net
そういうのもいいから、もう仲良く行こうぜ
数年前と違ってどうせいつも決まったメンバーしか来ない過疎スレなんだから
947:Name_Not_Found
15/07/09 02:47:15.09 .net
>>929
自演までするなんて、本当ここ痛い奴多すぎだろ
948:Name_Not_Found
15/07/10 08:29:48.72 .net
また、荒らしが新スレを立ててるね
ｽﾚﾘﾝｸ(hp板)
949:Name_Not_Found
15/07/10 20:06:05.70 .net
このページの3つ目のリークモデル（クロスページリーク/DOM挿入順序リーク)で
何がリークするのかいまいち分からないのですが、どなたか分かる人居ますか？
URLﾘﾝｸ(msdn.microsoft.com)(v=vs.85).aspx
それから、このドキュメントは古い(2006.02)のですが、今もこれはリークするのでしょうか？
対象はchromeとFFの最新版だけでいいです。
こちらで試したところ、chromeでは小修正で動かせましたが、リークはしていないように見えました。
ただし docmuent.create("<div onClick='foo()'>") が出来ず、
document.create('div');parentDiv.onclick= と分解したため、
> スクリプトがアタッチされた状態で DOM 要素が作成されることです。
に該当せず、無効化してしまっている可能性があります。
MSDNなのでIEでも試してみましたが、私がIEに不慣れなため、動かせませんでした。
見たところ、子DOM要素が親DOM要素のスコープを保持する必要がある時に起こるようですが、
これが必要となる仕様なんてありましたでしょうか？
950:Name_Not_Found
15/07/10 20:30:19.87 .net
> 私がIEに不慣れなため、動かせませんでした。
え？ なんで？
951:Name_Not_Found
15/07/11 04:33:24.52 .net
>>見たところ、子DOM要素が親DOM要素のスコープを保持する必要がある時に起こる
記事とこのスレを100億回読み直せ
子DOM要素が親DOM要素の参照を持つのは当たり前だし、そこに書いてあるのはこのスレの上で議論されたことに過ぎない
952:Name_Not_Found
15/07/11 20:21:31.83 .net
MSDNだろうが個人ブログだろうが、ことJSに関して10年前に書かれた記事の内容が今も通用することなんてほぼない
953:934
15/07/11 23:05:41.24 .net
しかし未だに循環参照はリークするんだろ？
勘違いしている奴が多いと思うが、あれはCから見ればブラウザのバグでしかない。
ルートから辿れないノードに対してDOMとJSHeapを同時にGCすれば済むだけの話だ。
むしろJavaScriptをやるようになってブラウザのポンコツ加減に驚いた。
removeEventListenerだって本来はGCできるがしていない。これも手抜きでしかない。
実装上、自分でremoveした方が速く動く。
だからユーザー側にタイミングを委ねる仕様を残すのはいい。
しかしブラウザが落ちるようなところまで来たら、
低速でも完全性のあるGCを動作させて落ちるのを回避しないとプラットフォームとしては使えない。
JavaScriptを書く連中もそうだが、ブラウザを開発する側も「再起動すればいい」という甘えがある。
954:Name_Not_Found
15/07/12 00:21:36.83 .net
そうですか。
質問どうぞ。
955:Name_Not_Found
15/07/12 00:36:44.61 .net
>>938
今はもうしないって何度も言われてるだろ
しつこい
956:934
15/07/12 01:10:18.52 .net
>>940
それ本当か？
循環参照の話はググレば山ほど出てくるし、記事も最近のも多いから、実際にリークするんだと思うぞ。
JSHeapだけの循環参照は最初からリークしない。
DOMとJSHeap間の循環参照がリークする。(これはGCを別々にやっているから。だから同時にやれば直る。)
よくあるBadCaseとして書かれているごく単純なのは無駄なクロージャを作らなくなったからリークしなくなったらしい。
removeEventListenerなんて最初から要らない仕様にするべき。(DOMをGCしたときに同時にGCすればいいだけ）
ただ、確かに対策は簡単なので、対策されているかもしれないが。
まあいいや、俺の本筋はそこではないので。
957:934
15/07/12 01:11:06.00 .net
934の質問は以下ね。
・DOM挿入順が速度最適（ツリーを完成させてから最後に挿入）の場合は今でもリークするのか？
・親DOMのスコープを子DOMが保持することが仕様として必要なのか？
(仕様としてこれが必要である場合は、今でもリークするし、回避する手段も実装側にはない。
ただ、これはよく知られた速度最適化に反するので、実装だけの問題なら既に修正されている可能性が高い。)
答えられる人が居たらよろしく。
あとついでに、
・chromeのタスクマネージャのJavaScriptメモリも増えず（ずっと20MB(ライブ10MB)程度）、
・chromeのDevToolのProfilesでSnapShotを取っても大して増えず(5MB-10MB程度）、
・外部のProcessExplorerで見たVirtualSizeも800MB程度でほぼ一定なのに、
chromeが落ちるのだが、何かピンと来ることがあれば。
なおOSの仮想メモリは十分に余っている状態。
ある程度の時間は確実に動き、その後のある程度の時間のうちに落ちるので、リークだと見ていたが、
Virtualが800MB程度だから、何かのリソース枯渇かとも思えてきた。ただ、いずれにしてもよく分からない。
これも気長に待つので、答えられる人がいればよろしく。
958:Name_Not_Found
15/07/12 01:39:09.96 .net
オブジェクトをnewして配列に入れていく
処理をするとメモリ使用量がどんどん増えていきます。
やっぱりメモリリークは有るようですね。
959:934
15/07/12 01:52:35.48 .net
>>943
それはGCしてないだけ。
chromeのDevToolのTimelineにあるゴミ箱ボタンを押せば手動でGCを起動できる。
押せば減ると思う。
減らないようなら、ここにソースを晒せば誰かが原因を指摘するかも。
960:Name_Not_Found
15/07/12 01:57:55.26 .net
ちなみにFFなら about:memory でメモリプロファイルが見える。
verboseにすれば1バイト単位で計上してくれる。
そこにGCボタンもある。
IEは使ってないので知らない。
961:Name_Not_Found
15/07/12 02:36:12.87 .net
>>944
こんな感じで再現するよ
var a = [];
while(true) {
a.push({})
}
すごい勢いでメモリがリークしていく。
962:Name_Not_Found
15/07/12 06:45:33.62 .net
>>946
それはリークではなくて、実際に使っているだけ。
リークというのは934の例を見てくれれば分かるが、
どこからもどうやっても参照できないのにメモリが解放されない場合のことを言う。
てか申し訳ないが、今の君が僕の質問に答えるのは無理だ。
僕の質問に付随する内容として僕が積極的に回答するのはここまでにしておく。
君自身の質問としてなら続ければいいけど、さすがにそれだと無視されると思う。
963:Name_Not_Found
15/07/12 08:02:18.24 .net
>>946
まさかこんなコードじゃないだろうよと思っていたコードがそのまま出てきて、どこから突っ込んでいいのやら…
964:Name_Not_Found
15/07/12 17:25:44.77 .net
>>942
結論から言うとしない。
URLﾘﾝｸ(steps.dodgson.org)
965:Name_Not_Found
15/07/12 19:13:24.98 .net
>>949
ありがとう。
循環参照は全て対策されているということについては了解した。
(ただそれは>>938,941に対する回答だ。>>942に対しての回答もあればよろしく)
一応コメントを残しておく。
> GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理系の GC に追跡されていない。
この部分が擁護的で間違っているが、V8はC++で書かれているので、実際はJavaScript側もC++で扱っている。
言語間で連携する必要なんてない。最初から全部C++だ。
一般的にヒープ内部構造まで仕様で規定することはないので、JavaScriptもそうだとするなら、
コードは全てC++でJavaScriptHeapも好きな構造に出来るので、それが扱いづらいのなら実装が悪いだけ。
> 世代をまたぐだけでも大変なのに、更に言語をまたげなんて無理難題にも程がある。
ここからも筆者が勘違いしている事が分かる。言語は跨がない。
しかし構造からしてV8はDOM以外用にチューニングされている。ブラウザ用ではない。
DOMが最初からあるのなら、DOMとJSHeapは混ぜてしまったほうが実装しやすいはず。
ここら辺は
> ふつうの解決
に書いてあるとおり。
966:Name_Not_Found
15/07/12 19:23:40.14 .net
> V8はC++で書かれているので、実際はJavaScript側もC++で扱っている。
そんなわけないｗ
例えばRuby実行エンジンはC++で書かれているが
Rubyは当然Rubyだ
967:Name_Not_Found
15/07/12 19:32:59.43 .net
>>950
DOMとES5は別々に仕様が策定されているわけで仕様を実装する立場からしたら、ScriptエンジンとDOMエンジンを分けたくなる気持ちはわかるけどな
あなたのいう理想を実現するなら JavaScript API 関連仕様全てをひっくるめて一つの仕様を策定するところから始めないといけない
ある一つの仕様に変更が加えられるたびに「たった一つの仕様」を全て見直して仕様化し直すコストがかかる
> ここからも筆者が勘違いしている事が分かる。言語は跨がない。
あなたのいう理想は「自分で一から仕様を作って自由に実装できるコード」に限定されているように見える
分化された仕様から実装する場合には効率が悪すぎると思うんだけど、どうだろうね
968:Name_Not_Found
15/07/12 20:02:54.30 .net
>>951
お前は付いて来れていない。
JavaScriptからはJavaScriptHeapを直接扱えない。set/get等ができるだけだ。
当たり前だが一般的にGCが出来る言語はGC部分の直接操作はできない。
オブジェクト志向的説明の方が分かりやすいかもしれない。
JSHeapはJSインタプリタから見るとオブジェクトだ。
つまり、JSHeap内部構造はJSインタプリタからは完全に隠蔽されており、set/get等のメソッドが提供されているだけだ。
JSHeapオブジェクトはC++で記述されており、内部構造も動作も自由に書ける。
これで分からない奴にここで説明しきるのは無理なので、この件についてもここで打ち切る。
969:Name_Not_Found
15/07/12 20:37:54.28 .net
>>952
> DOMとES5は別々に仕様が策定されている
なるほど、そういうことか。了解した。
> 分化された仕様から実装する場合には効率が悪すぎると思うんだけど、どうだろうね
これはその通りだ。
DOMとECMA、ついでにCSSの仕様が非同期で更新されるのなら、
それぞれのコードが干渉しないようにしておかないと面倒になる。
ただ、V8を書く時には最初からDOMもJavaScriptもある程度仕様が固まっていたはず。
そこでDOMを付け足すような構造にするのは、DOMを最初から捨てているように見える。
(Nodeとかだとそれでもいいのだが）
というか、JSオブジェクトはツリー構造を取れるから、DOMも普通にJSHeapに載せられるはず。
逆に、JSHeapも構造を規定されていないし、V8のケースならそれぞれ単品で浮いている感じだから、
C++のヒープ構造をJSHeap側が踏襲する手もあったはず。
なぜわざわざ難しくなるようなアプローチをするのかがよく分からん。（歴史的経緯があるのだろうけど）
コードが混ざるのはまずいが、実行時のHeapは共有で一つでも問題ないと思うのだが。
GCに関しては、「ルートから辿る、遅いけど完全なGC」は今のV8の物より断然簡単に実装できる。
だから実装されていないのが謎だったのだが、
参照カウンタ方式の「速いけど完全にするには難しいGC」を実装しきる方向でやっているというのは分かった。
しかし落ちる間際位は「遅いけど完全なGC」を実行してくれよというのが俺の気持ち。
970:Name_Not_Found
15/07/12 23:34:34.49 .net
昔のIE+ActiveXのメモリリークを不完全に理解した気になったやつらがいまだにC++とjavascriptがーとかいってるのはひどく残念
971:Name_Not_Found
15/07/13 00:34:33.35 .net
>>949
質問者ではござらぬが、このブログがあまりにも凄いのでつい。これたいへんな文章量だすな。分かりやすい上に例示が秀逸。書かれたこのお方を尊敬しますし見つけたあなたにも敬服いたしました
972:Name_Not_Found
15/07/13 00:57:56.91 .net
それは誠でござるか
我もとくと拝見するでござる
973:Name_Not_Found
15/07/13 04:28:19.94 .net
>>950
言語云々というよりV8はあくまでV8内の閉じられた世界だけを管理するもので、
当然組み込み先の他のGCシステムまで介入することはなかった。
汎用的なエンジンだからあまりBlinkに特化するわけにもいかないから、
汎用的な連携APIを用意してマシになったということだ。
また、DOMで子が親を参照するのは当然必要で、parentNodeがまさにそうだ。
974:Name_Not_Found
15/07/13 04:31:42.82 .net
DOMはJSのためだけのものではないし、逆も�
975:ﾜた然り。 V8もBlinkのためだけのものではないし、Blinkも当然Dartなど 今後他のものとも連携が取れないといけないかもしれないのであまりに密結合にすることはできない。
976:Name_Not_Found
15/07/13 19:49:41.40 .net
>>954
あなたのいうJSHeapとは何？
- オブジェクトのツリー構造
- ブロトタイプチェーン
- スコープチェーン
- DOMのツリー構造
>>958もいってるけど、オブジェクトとDOMでは親を辿るAPIが違う
そもそも、DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
ESにはその他にも様々な参照構造があり、それぞれにheapが存在するものと想像する(実際は知らないけど、上記全てを一つのheapで管理するのはどう考えても現実的じゃない)
>>952の指摘でも感じたけど、あなたは実装面には強いけど仕様に明るい方ではないよね
もう少し、仕様についても勉強した方がいいかと
977:Name_Not_Found
15/07/13 21:25:35.32 .net
まあ全部JSでブラウザを作ろうというプロジェクトもあるし～
最近のモダンブラウザはBlink-in-JS構想とかで徐々にDOMをJS化してきてるし～
今日のことが明日通用しない業界だし～
どうでもいいよね～
978:Name_Not_Found
15/07/13 23:51:58.78 .net
>>958
> また、DOMで子が親を参照するのは当然必要で、parentNodeがまさにそうだ。
だから最初から何度も言っているが、
・子DOM要素が親DOM要素の『スコープ』を保持する必要
・スコープ
・スコープ
・スコープ
子DOMが子DOMのスコープ内に親DOMをもつのはparentNodeが有るからこれは必要。
しかし子DOMが親DOMのスコープを保持する（親DOMから何が見えるかを直接知っている）必要があるのか？ということ。
普通は一旦親DOMを参照した後に、その親DOMのスコープを見ればいい。だから直接もつ必要はない。
しかしMSDNでは、
> 動的に作成された 2 つのオブジェクトどうしを一時的にアタッチして子要素から親要素へのスコープを作成するのが基本的なパターンです。
> 後でこの 2 要素のツリーをプライマリ ツリーにアタッチすると、その両方がドキュメントのスコープを継承し、一時オブジェクトがリークします。
つまり、DOMに親子関係が発生した時にそれぞれスコープを作成して、---(A)
プライマリツリーにアタッチした時にこれらは両方とも変更され、---(B)
結果、(A)がリークすると言っている。
これが起きるのは、
・（A）内部に循環参照がある＝子DOMのスコープと親DOMのスコープに循環参照がある---(α)
・（B）で差し替えられるのは親DOMのスコープのみ＝子DOMが親DOMのスコープを直接保持したままでこれがリーク---(β)
のどちらか。俺は後者だと思っていたからこの質問になっていた。ただ、今から考えれば前者かもしれない。
繰り返しておくが、
○ 子DOMと親DOMに循環参照がある。(parentNode, childNode)
？ 子DOMのスコープと親DOMのスコープに循環参照がある。
？ 子DOMが親DOMのスコープを保持している。
○ 子DOMが子DOMのスコープ内に親DOMを保持している。(parentNode)
これらは全く別物だ。スコープは「スコープオブジェクト」として別に作った方が実装が楽だから、多分そうなっている。
そしてここでリークすると言っているのはその「スコープオブジェクト」であって、「DOMオブジェクト」ではない。
対策は「一時的なアタッチをなくす＝（A）の作成をしない」となっている。
結果的にリークするオブジェクト(A)そのものを作成しないのだから、当然対策できることになる。
979:Name_Not_Found
15/07/13 23:52:34.90 .net
(α）のpatch対策は簡単で、DOMをアタッチする時にそのDOM以下のツリーのスコープオブジェクトを全部GCすればいいだけだ。
ただ、循環参照の対策が出来ているのなら通常のGCで回収できることになるから無駄patchになる。
だから循環参照の対策が根本対策で、こちらを急ぐのが開発方針として妥当で、おそらくこれだろう。
ただ（α）だと書き換えるスコープオブジェクトの数が多く、遅い。
最小限に絞って高速化すると（β）になる。だからこちらを仮定していたのだが、
IEは実際遅いし、循環参照の対策も出来ているのなら、（α）なのかもしれない。
（β）の実装で無理があるともあまり思えないのだが。
もう一度繰り返すと、(>>942)
> ・DOM挿入順が速度最適（ツリーを完成させてから最後に挿入）の場合は今でもリークするのか？
> ・親DOMのスコープを子DOMが保持することが仕様として必要なのか？
俺は後者の仕様はないと思っているし、従って前者も対策されており、リークはないと見ている。
だから、これが間違っていそうなら指摘よろしく。
対象はchromeとFFの共に最新版だけでいい。
980:Name_Not_Found
15/07/13 23:57:19.86 .net
>>958,959
見る限りV8のDOMはおまけだ。ただ、そういう用途があるのかはよく分からない。
ブラウザから離れるのなら、最初からnative(exe)が使える。サーバーサイドは基本的にこれだ。
スクリプトの方が運用が楽だし、スレッド起動できるから今は速いわけだが、
exeをスレッド起動できる仕組みが出来ればスクリプトエンジンは全部抹殺されても不思議ではない。
(DLLの動的『指定』とか)
もちろん速いスクリプトエンジン自体は需要はあるし、JITならさほど遅くもないから、こちらに賭けるという選択だとも見える。
しかしNodeはC->JavaScriptは呼べるが、逆はできない。つまり本体はCで、JavaScriptをブラウザ/WEB用APIとして使う方向だ。
nativeが使える状況で速度至上主義なら、C系以外の選択肢は事実上無い。だからNodeの選択は妥当だ。
もちろんNode自体を動かすためにV8が必要だとしても、若干ここら辺に違和感を感じるのは事実だ。（統一感がない）
そもそも速い共通バイナリならJavaでよかったのだが、chromeはそれも外した。(NPAPIの廃止）
Javaについては他に問題がありすぎるようではあるが。
なお、密結合にはならない。
元々1つの物(DOM)を、2箇所(Blink/V8)から管理するからおかしいことになっている。
見る限りDOMとJSのオブジェクトは相似形だから、同じHeapで同居できるはず。
だから、Blink/V8/JSHeapと分離し、BlinkとV8内部には個別のHeapを持たず、全部JSHeapに突っ込めばいい。
wrapperというコピーが無くなるので、メモリ使用量は減る。
GCはすべてJSHeapに任せられる。単一で内部的にツリーを構成できているから、
「GCされないために云々」という無駄コードを全て捨てられ、プログラムとしては綺麗になる。
ただ、各エンジンとHeapが粗結合になるので、どうしても動作が遅くなる。
(Readはpublic（というか直接ポインタアクセスで動的保護無し）、
Writeはprivateという指定が出来ればいいのだが、これができる言語は多分無い）
だから高速エンジン制作者には不評だろうけど。
とはいえ、Mozillaがやろうとして失敗したようだから、何か他にも問題があるのだとは思う。
981:Name_Not_Found
15/07/13 23:59:43.55 .net
>>960
> あなたのいうJSHeapとは何？
JavaScriptのHeapと書くと長いから、JSHeapと書いているだけ。
ただこの質問は君にはプログラミングセンスがないことを示している。
君には理解不能だろうけど。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
何故？そんなことはあり得ない。例えばPCのデータはHDDで全てまかなえている。
やり方次第だ。無理に纏めるのは効率が悪いが、同じ型、同じ物を別々に扱うのはもっと効率が悪い。
localStrageだってkey/value型しかないが、やり方次第でどうとでもなる。そういうものだ。
実際にDOM.jsは動いているんだろ？だったら少なくともJSHeapに突っ込んでもなんとかなるんだよ。
> あなたは実装面には強いけど仕様に明るい方ではないよね
これはその通り。JavaScript歴は半年だからね。
ただそれ以上に君にはプログラマーとしてのスキルがないよね。
> もう少し、仕様についても勉強した方がいいかと
何故？俺はGM使いで、だからJavaScriptを使っているだけだ。
今現在で一通り、やりたいことは書けるようになった。
俺がブラウザを作るのなら仕様を一通り読む必要があるが、その予定はない。
その程度でグダグダ言うなと言うのなら、無視してくれて構わない。
982:Name_Not_Found
15/07/14 00:03:30.93 .net
>>960
君は何のために俺に対してレスを付けているのだ？
俺に対して文句を言いたいだけか？それならいくらでも言えばいいが、無駄だから今後は無視させてもらう。
俺は今、chromeが勝手に落ちる現象に遭遇して困っている。
>>942に書いたとおり、DevToolには現れないが、確かに安定して落ちるので何か原因がある。
だからそれに関する手がかりになりそうな奴にはレスを付ける。
958,959に関しては、俺に対して何かしら情報をくれようとしているのだから、こちらもそれなりに返す。
960に関してはどう返せばこちらの実になるか分からないし、それ以前にどう返して欲しいかも分からない。
仕様を勉強してない奴は黙れというのなら、
仕様を与えられても実装できない君みたいなエセプログラマはもっと黙るべきだ。
仕様は聞けば済む話だが、スキル/センスがないのはここでいくらやりとりしても解決できる話ではない。
君は俺より実装面で弱いという自覚があるようだが、ならば何故その実装面の話に低レベルな横槍を入れるのだ？
質問案件に対し、知っている奴が分かる範囲で気が向いたら答えるのが質問スレの普通のやり方だ。
君のレスは誰のためにも何のためにもならない。
初心者用スレとして維持したいのであれば、俺は「ECMAScriptデス4」に移動してもいい。
俺にレスをくれている奴らの多数決でいい。
> DOM要素ノードはオブジェクトでもあるわけだから同時に2つのheapが発生することは避けられない
Dom.jsでも読めよドアホ。
もう少し、自分が至らないことについて自覚した方がいいかと
983:Name_Not_Found
15/07/14 01:52:01.76 .net
／⌒ヽ
/ ´_ゝ`）すいません、ちょっと通りますよ・・・
| /
| /| |
// | |
Ｕ .Ｕ
984:Name_Not_Found
15/07/14 10:30:45.85 .net
>>962
おそらくページ遷移時のCG順序か機構に問題があって、特定の場合に中間構造がリークするのだろう。
中間構造はドキュメントに接続された際にもう捨てていいはずだが、
JSとの絡みで必ずしも捨てられないケースがあるのか、バグでそうなっていたのだろう。
>>963
今はしない。
>>964
DOMの管理含めて丸ごとJSで組み立てられればラップなんて仕組み必要無いが、
実際にはDOMはレンダリングともつながっているわけで
ブラウザネイティブの世界から大きく切り出すことは出来ない。
985:Name_Not_Found
15/07/14 11:11:23.28 iGbd+ivb.net
URLﾘﾝｸ(blog.jquery.com)
jQuery 3.0 and jQuery Compat 3.0 Alpha Versions Released
jQuery 3.0きた！ アルファだがな。
Major changes
* Simplified .show() and .hide() methods
* Special case with .data() names
* jQuery.Deferred is now Promises/A+ compatible
* Removed special-case Deferred methods in jQuery.ajax
* Error cases don’t silently fail
* .width(), .height(), .css(“width”), and .css(“height”) to return decimal values (whenever the browser does)
* Removed deprecated event aliases
* jQuery.swap, jQuery.buildFragment, and jQuery.domManip are no longer accessible on the jQuery object
* Animations now use requestAnimationFrame
* .unwrap( selector )
* Massive speedups for some jQuery custom selectors
基本的に互換性は保たれているらしい。
個人的にはDeferredがPromises/A+互換になったことが嬉しい
986:Name_Not_Found
15/07/14 11:45:53.25 .net
相変わらずの信者脳だな
987:Name_Not_Found
15/07/14 13:33:39.65 .net
> As an added bonus, both jQuery and jQuery Compat will
> include support for Yandex.Browser, a freeware browser released in 2012.
なんだ？ Yandex.Browserって
988:Name_Not_Found
15/07/14 13:36:04.50 .net
へー
URLﾘﾝｸ(weekly.ascii.jp)
> ロシアの検索市場でグーグルを圧倒するYandex、次にGoogle Playを狙うワケ
URLﾘﾝｸ(www.itmedia.co.jp)
> ロシア検索最大手のYandexが、Chromiumベースでミニマルデザインの
> 新ブラウザ「Yandex.Browser alpha version」をリリースした。
989:Name_Not_Found
15/07/14 16:24:28.23 .net
宣伝うざい
990:Name_Not_Found
15/07/14 16:31:11.58 .net
宣伝をわざわざ貼るくらいこのスレには価値があるということだよ
991:Name_Not_Found
15/07/14 16:37:36.30 .net
別に宣伝じゃなくて、Yandexってなんだ？って思っただけ？
992:Name_Not_Found
15/07/14 17:01:51.96 .net
宣伝云々は荒らしに対してじゃないの
993:Name_Not_Found
15/07/14 17:28:47.88 .net
>>975
ここで質問する必要ないだろ
994:Name_Not_Found
15/07/14 17:35:48.85 .net
俺は別に質問などしてないけど？
995:Name_Not_Found
15/07/14 17:59:13.18 .net
> なんだ？ Yandex.Browserって
996:Name_Not_Found
15/07/14 20:06:29.40 .net
それは俺じゃない
997:Name_Not_Found
15/07/14 20:33:58.02 .net
>>980
>>972だって同じ
ライブラリの話題禁止と書いてあるだろ
998:Name_Not_Found
15/07/14 20:39:10.88 .net
ライブラリの話題じゃないだろｗ
999:Name_Not_Found
15/07/14 20:40:15.07 .net
ブラウザの話題だ
1000:Name_Not_Found
15/07/14 20:43:36.59 .net
>>982-983
ブラウザの話題はもっと関係ないだろ
ブラウザスレでやれ
1001:Name_Not_Found
15/07/14 20:45:43.99 .net
雑談ぐらいいいだろｗ
1002:Name_Not_Found
15/07/14 21:15:40.37 .net
スレ違いの話題に便乗してスレ違いの話題を広げると他の人に迷惑がかかるだろ
常識で考えろ
1003:Name_Not_Found
15/07/14 22:31:18.37 .net
>>968
ブラウザネイティブ＝HTMLレンダラじゃないのか？他の用途は特になさそうだが。
Wikiを見る限り、レンダラとJSエンジンが別なのは歴史的経緯だ。
1998 KDE(KHTML/KJS)
2002 WebKit(WebCore/JavaScriptCore)
2013 Blink(Blink/V8)
切り出すのは出来ないのではなく、今更やるのは大変であり、意味がないからだ。
今ゼロからソースを書くのであれば、
共通のデータストアを用意し、そこに入れさえすれば後は全自動の方が楽だ。
ただ、別Heap方式で実装しきってしまっているようなので、今更切り出す意味はない。
リークに関しては、こちらと同じ見解だということで了解した。ありがとう。
個人的にはMSの技術力は認めているので、何故そんな実装になったかが引っかかるが、
IEはAjax以前からあったから致し方なく、ドキュメントも古いからそんなもんだということにしている。
1004:Name_Not_Found
15/07/14 23:26:32.79 .net
>>987
いいかげんスレ違いの話はやめろ
1005:Name_Not_Found
15/07/15 02:22:48.35 .net
>>987
JSエンジンとレンダラだけについてではなく、
JSエンジンとレンダラ（ブラウザ本体）とDOM管理について話している。
例えばDOMが変更されたら再描画しないといけない。
DOMツリーとレンダリングツリーは密接に繋がっているので、
DOM管理をJS側に持っていくほうが普通に考えると非効率だ。
1006:Name_Not_Found
15/07/15 09:28:12.98 .net
なんかスレチに過敏な方が約一名おられるようで
誰も困らないから多少は見逃せば？
あまりにも続くようだと注意すればいいが何でもかんでも言ってるとスレの雰囲気悪くなる
1007:Name_Not_Found
15/07/15 10:41:13.35 .net
jQueryとlodash以外のスレチは絶対許さない人がいるんだよ
1008:Name_Not_Found
15/07/15 11:22:36.01 .net
アホか、いつjQueryとlodashを認めた？
jQueryとlodashを含めてスレ違いは禁止に決まってるだろ
1009:Name_Not_Found
15/07/15 12:27:16.00 .net
どうでもいい
荒らす気がないのならいい
一度決めたことが未来永劫通用する業界じゃないし
例えばこれからはWASMの範囲だってサポートしていかなきゃならんだろ
1010:Name_Not_Found
15/07/15 12:43:25.99 .net
Web業界の常識とスレのローカルルールの違いも理解出来ない人がいるのね
1011:Name_Not_Found
15/07/15 13:16:00.86 .net
スレチを叩く自治うざい！ じゃあjQueryとlodashを許容しよう！
とはなりませんでした～
1012:Name_Not_Found
15/07/15 13:26:50.02 .net
次スレ誘導
お好きなスレにどうぞ
+ JavaScript の質問用スレッド vol.121 +
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.122 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 +(c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.123 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
+ JavaScript の質問用スレッド vol.125 + [転載禁止](c)2ch.net
ｽﾚﾘﾝｸ(hp板)
1013:Name_Not_Found
15/07/15 13:51:29.57 .net
>>996
乙
1014:Name_Not_Found
15/07/15 22:48:23.38 .net
>>994,995
正直言ってスレのルールなんて関係ない。
1015:Name_Not_Found
15/07/15 23:10:37.85 .net
>>989
多分、そういう議論を繰り返して平行線で今があるのだと思う。
実際、DOMを変更するにしてもHTMLではなくJavaScript側からしかできないだろ？
どっちにも密接なんだよ。
経緯から推測すると、googleはV8でDOMを管理しようとして、これを要求したが、
既にWebCoreで管理していたWebKitからするとウザいだけで、APIの提供で終わった。
googleはこれ以上の高速化にはV8で管理するのが不可欠と見てBlinkにフォークした。
WebKitはV8用のコードをすべて捨てるつもりらしいから、
逆に言えばV8専用のコードがそれなりの量あるということ。
つまりJavaScriptCoreはWebCore内のDOMを直接参照に近い方法で見ていることになる。
Blink： レンダラ+（DOM+V8)
WebKit： (WebCore+DOM)+JavaScriptCore
俺： レンダラ+DOM+JavaScriptエンジン
ということ。どの実装も出来る。上2つは実際にブラウザになっているので、結果は出るだろう。
1016:Name_Not_Found
15/07/15 23:14:37.85 .net
梅
1017:１００１
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
1018:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています