Reactでレンダリング回数やレンダリングにかかる時間をユニットテストでテストできるライブラリを開発しました - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
各種メモリ／ストレージのアクセス時間，所要クロックサイクル，転送速度，容量の目安 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 各種メモリ／ストレージについて，2024年時点で標準的なアクセス時間，所要クロックサイクル，転送速度，容量を，各種カタログスペックを参考にまとめてみました． レジスタ(レジスタファイル) 最近のCPUのレジスタ(register)のアクセスは，通常CPUの1クロックサイクルで完了します．2024年時点では，標準的なCPUのクロック周波数は，1〜5GHz程度のオーダーです．1GHzは1秒あたり10億回，すなわち1クロックサイクルは1ナノ秒です． したがって，2024年時点では，レジスタには0.2〜1ナノ秒程度でアクセスできると言えます．
RSpecで遅いテストを見つける - すがブロ
--profile オプションを使う 普段きちんとRSpecを使っている人にとっては常識なのかもしれません。というか普通にhelpに載っているので常識なのでしょう、、、。 RSpecで遅いテストを見つけるには、--profile オプションを使うと簡単に見つけることができます。 % bundle exec rspec --profile 3 .................................. Top 3 slowest examples (4.24 seconds, 61.5% of total time): Pooka Pooka::Master Worker#run worker received usr1 signal(signal_handler_thread Error) 1.41 seconds ./spec/pooka_spec.rb:86 Pooka Po
Haskell で高速なプログラムを書くときに注意すること | 雑記帳
Haskell は表現力が高いプログラミング言語だが、気をつけないと非効率的なコードが生成されてしまうことがある。では、どういうところに気をつければ高速なコードになるのか。少し調べてみた。 この記事に書くのは、あくまで原則とかそういうやつなので、コンパイラーの最適化（正格性解析、インライン化、自動ボックス化解除）によっては、自前で工夫しても意味がない、つまり、コンパイラーに任せた場合と同じ結果になるかもしれない。どういう場合に早くなるかはケースバイケースなのだ。 ここで扱うトピックは大きく分けると、 正格評価 型クラスの特殊化 Unboxed 値 その他 となる。あくまで自分用の備忘録であり、特に突飛なことを書いているつもりはないので、知ってる人はアーハイハイという感じで読み飛ばしてしまえるだろう。また、筆者の理解が浅く、誤解に基づいたことを書いているかもしれないので、あまり信じすぎないよ
Latency is Everywhere and it Costs You Sales - How to Crush it - High Scalability -
« Handle 700 Percent More Requests Using Squid and APC Cache | Main | Paper: Parallelizing the Web Browser » Update 8: The Cost of Latency by James Hamilton. James summarizing some latency info from Steve Souder, Greg Linden, and Marissa Mayer. Speed [is] an undervalued and under-discussed asset on the web. Update 7: How do you know when you need more memcache servers?. Dathan Pattishall talks a
#cto_sushi でChangeLogを追う技術、Sitespeed.io、DDDなどの話をした
#cto_sushiでChangeLogやIssueを追う技術、reftest、GitHubスパムなどについて話してきた。(この中に現在CTOはいなかった気がします) ログ: #cto_sushi - Togetterまとめ 久々に を食べるSushiイベントだった気がします。 これからの Web について真剣に議論している。 #cto_sushi pic.twitter.com/c3xXrkasVi — Jxck (@Jxck_) May 26, 2015 #cto_sushi pic.twitter.com/oAts18i7O3 — Yosuke FURUKAWA (@yosuke_furukawa) May 26, 2015 クリップボード API - kyo_ago 机が埋まる前にLTスタート。 クリップボードについて kyo_ago #cto_sushi — azu (@azu_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
文章レイアウトだけで読む速度が2倍に? 「読書アシスト」の読みやすさの理由
BitFunnel performance estimation · BitFunnel
