もじら組フォーラム

(環境: WinNT/Other)

>>>それと再生タイミングが揃ってなきゃいけないなんて決まりはないので、
>>>揃うことが重要と強調する意味が分かりません。
>>揃うようにスクリプト組んでますか？そのようには見えないのですが。
>>見落としているかもしれないと思うので、もし揃うようにスクリプトを組んでいる
> Chromeでは再生タイミングが揃うのです。

結果的にそうなっている「だけ」じゃないかと指摘しています。
そうなっている「だけ」なら揃うとかそろわないとか、考える意味がない。

> Firefoxは文字処理が遅いらしく
> そのせいで再生タイミングがズレていく様に見えます。

そのせいでというのが、何か意味がありますか？
そのせいでタイミングがずれていいなら、ずれていいのです。
ずれてけないのにずれているなら問題です。

> 逆に言うと、文字処理を速くすると解決するかもです。

文字処理を早くすることに意味はあるかもしれませんが、
そろえるように問題を解決していく必要はあるのですか？

>>本題の２回目以降が遅いというのはやはり気のせいだと思います。
>>あるとすると、GC の影響とかは考えられそうですが、私の目には
>>どう見ても誤差の範囲です。私以外の結果を見ても１回目よりも２回目以降の
>>ほうが早い場合があるので、必ず１回目が早いということはありません。
> のらねこさんの結果から
> >こちらの結果。１回目が必ず早いとは
> >Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
> >Very Heavy Load Memory Speed Test Time 469 msec ・・・ 112 msec　合計　581 msec
> >Very Heavy Load Memory Speed Test Time 852 msec ・・・ 210 msec　合計 1062 msec
> (1062÷581≒1.82 タイムが 182%　に延びている ← 合計は１回目より遅い )

見方がおかしい。遅いものと速いものをごっちゃにして比較してはいけない。
100000 sec
100001 sec
これはほぼ同じようなものです。
0.0001 sec
0.0010 sec
これは大分違います。
100000.0001 sec
100001.0010 sec
ほとんど変わりがありません。が、２番目のほうが大きいです。
さて、

Very Heavy Load Memory Speed Test Time 469 msec
Very Heavy Load Memory Speed Test Time 852 msec
Very Heavy Load Memory Speed Test Time 428 msec
Very Heavy Load Memory Speed Test Time 485 msec
Very Heavy Load Memory Speed Test Time 554 msec
Very Heavy Load Memory Speed Test Time 490 msec

平均 546.3333
最小値 428（平均の0.7834045）
最大値 852（平均の1.559488）

Very Heavy Load Storage Speed Test Time 112 msec
Very Heavy Load Storage Speed Test Time 210 msec
Very Heavy Load Storage Speed Test Time 98 msec
Very Heavy Load Storage Speed Test Time 118 msec
Very Heavy Load Storage Speed Test Time 145 msec
Very Heavy Load Storage Speed Test Time 115 msec

平均 133.0
最小値 98（平均の0.7368421）
最大値 210（平均の1.578947）

こうして並べてみたときに、２回目は遅いですが、１回目が遅いといえますか？
たとえば、３回目と比較して１回目は遅いです。１回目が早いとは言えません。
平均から見れば早いですが、測定で得られている値はずいぶん揺れがあります。
若干早い傾向があるとはいえ、その揺れの範囲に収まってしまっています。
つまり、１回目と２回目以降は大差がないとみるべきじゃないでしょうか？

> Storage Speed Testでは、逆に Chrome が遅いのです。1000ms ぐらいあります。
> 古いChrome4ではもっと遅く 10000ms ぐらいだったから改善されている。
> Chromeとは別にSafariのStorageはHDD保存前にMEMキャッシュを持っていそうで超高速なんです。
> 8msなんて数字もありましたから・・・調べる意味はあります。

8ms は早すぎます。処理をしていない可能性があります。
最適化が行われた結果意味のない処理は削除され、コード自体が実行されていない
ということも考える必要があります。C で見る場合などは ASM に落ちた時に
どのようになっているかを確認したりする場合もあります。
Javascrip の場合、最終的にどのようにコンパイルされたか知るすべはないので、
意図通りに処理が行われている保証はありません。

>>どちらも動画を再生している意味が分からない。
>>動画再生で CPU やらメモリやらに負荷をかけてるつもりでしょうが、
>>ブラウザ間の比較をするにはデコード性能が悪いのか、スクリプトが遅いのか　> わからない。
> >>あと結果もどれもキャッシュという意味ではキャッシュ効いてないんじゃない？
> >>Storage Speed Test どれも誤差程度で、その差が有意であるようには見えない。
> >>なので、そのことについてどうこう言うこと自体の意味がない、と思えます。
>
> キャッシュ効いてないと言うか、文字処理が遅いので
> キャッシュ処理している最中に遅くなっているかもしれません？

そこ、キャッシュ処理がどう関係があるかわかりません。

> 動画再生よって何らかの負荷を与えてるだけですから。つまり負荷はブラックボックス。
> ブラウザだけ変えて、同じPCで同じ負荷を与える・・・詳細でなくても一部分の概要的評価ならできる。

負荷がブラックボックスになってしまうと同じ負荷かどうかが分からないのですが。
ブラックボックスとしていいのは同じであるといえるものだけです。
つまりブラウザ実装によって異なる可能性のあるものは同じ負荷とは言えません。
たとえばハードウェアデコーダに処理を投げている場合とソフトウェアデコーダ
で処理している場合では、CPU やメモリの負荷が桁違いに異なります。バッファリング
先読みの仕方でも異なります。
分かりやすく言うと Windows Media Player と Video Lan Client で再生負荷を
比較すると動画再生なんだから同じ負荷がかかる、と言っているわけです。
同じプレーヤーでもハードウェア支援が有効になっている場合、CPU の再生支援
機能が有効なものとそうでないもので CPU への負荷のかかり方は大分違います。