DIV ⇒ SVG 移行して気付いたこと - ジンジャー研究室
マップ閲覧・編集システムで画面上に DIV で描いていた図形を SVG に移行した。内部に数百のオブジェクトを含む要素の動作が重く、ドラッグしたときにカクカクになる問題を解決したかった。ちなみに Virtual DOM は使っているがすでに最適化は済んでおり、毎回描画されるような事態はあらかじめ避けている。代替案として Canvas と迷ったが CreateJS のようなライブラリを使わないとイベントハンドリングがきついので、 SVG で行けるならそれが一番。以下、移行した結果と移行中に気付いたことのまとめ。 描画パフォーマンスが上がった（Firefox: 20fps ⇒ 60fps、Chrome: 50fps ⇒ 60fps）。 Chrome の DevTools で見ると、DIV 版は UpdateLayout と Paint に時間がかかっているが、 SVG は Layout に時間
RubyBench - Long Running Ruby Benchmark
What is RubyBench? RubyBench is a long running Ruby benchmarking tool. Currently, Ruby benchmark scripts and Discourse benchmark scripts have been implemented and are run for every commit and release. If you've noticed a regression, feel free to use RubyBench when opening a new issue. Try out RubyBench! → What's the Plan? RubyBench is currently still in its early stages but has already proven to b
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
Ruby/Railsでの高速化の際に使うgem達 - Qiita
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
Ruby 製バッチ処理を省メモリ化した - おいちゃんと呼ばれています
少し前に Ruby 製のバッチ処理を省メモリ化したときの話をメモしておきます。 どのようなバッチ処理だったか 動画共有サイトにアップされた動画がオトナの事情によって削除されることがしばしばあるということは周知のことだと思う。そこで、一定時間おきに配信元サイトをチェックして、もし動画が配信元から削除されていたら、当該動画をこちらのサイトでも動画一覧に表示させないようにする、検索に引っ掛からないようにする、ということをやっていた。 便宜上、そのバッチ処理のことを「（動画の）存在確認くん」と呼ぶ。 oom-killer に殺されていた 彼は非常にデキる子だったが、なんか最近、動画の落とし漏れがあるなーと感じた。原因を調べたら、メモリを食い過ぎて oom-killer に殺されていた。 cat /var/log/messages Apr 6 12:46:45 xxx001 kernel: Out
Tuning NGINX for Performance
NGINX is well known as a high‑performance load balancer, cache, and web server, powering over 40% of the busiest websites in the world. For most use cases, default NGINX and Linux settings work well, but achieving optimal performance sometimes requires a bit of tuning. This blog post discusses some of the NGINX and Linux settings to consider when tuning a system. You can tune almost any setting, b
teppeis blog
追記: 2019/05/01 最近の@typescript-eslint/eslint-plugin, Prettierのアップデートによって、正式にTypeScript 3.4対応されました。一通り普通に動いてる感じ。 これまで自分で使っていて問題になったのがパフォーマンス。ESLint単体やTSLintに比べて、プロジェクトによるだろうけど2倍以上遅い。体感で結構辛い。 Poor performance on some projects · Issue #389 · typescript-eslint/typescript-eslint これはTypeScriptのパーサーを通す部分の構造上の問題が原因なので、簡単には直せなそうな気配。 とりあえず、個人的には型を必要とするルールにそこまでの価値を感じていないので、該当ルールを無効にしてparserOptions > projectを削
Snow in canvas land
Jake Archibald (@jaffathecake) is a Developer Advocate at Google working with the Chrome team to develop and promote web standards and developer tools. Prior to Google, Jake worked on http://lanyrd.com/mobile/, using modern web standards and good old hackery to work smoothly on ancient devices, while adding enhancements to newer devices such as offline support. Jake also spent 4 years working at t
HTTPパーサにおけるSSE4.2最適化の威力と注意点 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、サイボウズ・ラボの光成です。 PicoHTTPParserは@kazuhoさんたちが開発している高速なHTTPパーサです。 同じ作者によるHTTPサーバH2Oにも使われています。 11月4日の開発ブログによると、その時点でNode.jsなどに使われているhttp-parserの10倍程度の速度を誇るそうです（現在はhttp-parserも速度向上しその差は縮まりました。それでも4倍以上の差があるようです）。 該当ブログにはその高速化のためのノウハウが書かれていて大変興味深いです。ただIntel系CPUに搭載されているSIMD命令は用いられていませんでした。今回、@kazuhoさんと一緒に文字列処理専用のSSE4.2を用いることで1.7～1.9倍の高速化を達成しました（Improving Parser Performance using SSE Instructions (in
Ruby2.1+でのunicornのGCチューニング - Qiita
Strongly consider https://github.com/tmm1/gctools if using Ruby 2.1+ It is built on new APIs in Ruby 2.1, so it is more intelligent than this historical implementation. Ruby2.1+の場合は https://github.com/tmm1/gctools を使ってね、とのこと。 作者の記事: http://tmm1.net/ruby21-oobgc/ 日本語訳: http://www.sawanoboly.net/contribution/2014/3/13/ruby-21-out-of-band-gc READMEによるとruby2.1で提供されているapiとイベントを使ってGCの挙動を変更するらしい。したがってuni
Cより高速なCommon Lispコードを書く - 八発白中
Cで書くコードの方がCommon Lispで書くより速いって人がいたら、それは彼のCの技量が高すぎるってことだね。 “If you can't outperform C in CL, you're too good at C.” — Eric Naggum 最近、Common Lispの非同期Webサーバ「Wookie」を高速化する過程で、ボトルネックになっていたHTTPリクエストのパース部分を高速に処理するライブラリを書きました。 fast-http - A fast HTTP request/response parser for Common Lisp 既存のライブラリ「http-parse」よりも約10倍速く、Cのライブラリ「http-parser」より5%ほど高速です。 追記 (2014/10/26): 最適化をやり直し、現在は「http-parse」よりも約27倍速く、Cの「h
jQueryのパフォーマンス高速化Tipsまとめ | Webエンジニアのメモ
TweetPocket jQueryのパフォーマンス高速化Tipsまとめ jquery-logo jQueryのパフォーマンス高速化Tipsのヒントリストです。 セレクタのパフォーマンスのヒント 1. 常に#ID から辿る jQueryで要素を選択する最速の方法は、IDによるものです。 $('#content').hide(); $('#content p').hide(); 2. クラスの前にタグを使用 jQueryで2番目に早いセレクタは、タグセレクタ（$（’head’））です。 なぜならそれはネイティブJavaScriptメソッド、getElementsByTagName（）だからです。 最良の方法は、接頭辞にタグ名（およびIDから派生）を持つクラスです。 var receiveNewsletter = $('#nslForm input.on'); クラスセレクタは、jQueryの
さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
Vimの起動が遅い場合の原因と対策 — KaoriYa
Vimの起動にかかる時間は本来すごく短い。しかし使い方によっては長く(遅く)なってしまう。そうなる原因と対策を紹介する。 Vimは起動にかかる時間が短いソフトウェアです。この言葉に納得できない人はこの文章の残りをちょっと読んで行きませんか? 「Vimの起動、長い(遅い)なぁ」と感じているあなた、その原因が何か調べたことはあるでしょうか。Vimが遅くなる原因の95%はスクリプトの読み込み&実行にあります。「autoload化する」「–startuptimeを使ったことがある」?なかなかやりますね。でもautoloadは単に遅延させるだけで結局かかる総時間はかわりませんし、startuptimeで主にわかるのは各スクリプトの読み込みにかかった時間です。そのスクリプトがなぜ遅くなっているのか、どうすると速くなるのかを紹介しましょう。 遅くなる原因 回りくどいのはここまでです。遅くなる原因を列挙し
twihelp.me
twihelp.me 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Pythonコードの高速化ソリューションと言えばPyPyだよね〜 | TRIVIAL TECHNOLOGIES on CLOUD
PyPyはRPythonという文法的にちょっとした制約があるPythonを使う必要がある(大抵のコードはそのまま動くらしいけど)。そういう制限があったとしても，ほぼPurePythonなコードをPyPyで動かすだけでここまで高速化できるというのは驚きだ。 今年の夏に行ったEuroPython 2010でPyPyのセッションで，ちょうどJITの作者Antonio Cuniさんが話してた。トークが終わった後「PyPyのJITはなんで速いの？」との質問に答えてAntonioさん曰く「オブジェクトが持っているデータをメモリ上の固定位置に配置してるのが効いているみたい」と言っていた。この質問をしたのは実はセッションを聞きに来てたGuidoで，彼自身もPyPyにとっても興味があるみたい。 動的型付け言語の高速化手法はいろいろあるけど，PyPyのアプローチは副作用も少ないし，straightforwar
GAE/Python で HTTPリクエストを並列化 « Stop Making Sense
August 2011 (1) July 2011 (1) June 2011 (2) April 2011 (2) March 2011 (2) February 2011 (2) January 2011 (6) December 2010 (6) November 2010 (5) October 2010 (8) September 2010 (2) August 2010 (3) July 2010 (9) June 2010 (4) March 2010 (1) February 2010 (7) January 2010 (2) はじめに GAE/Python ではスレッドや子プロセス等による並列化が出来ないので、タスクキューを使うのが一般的です。 しかし、URLフェッチについては、非同期リクエストを利用することで、タスクキューを使わずに複数のHTTP通信を同時実行出来ます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - chrisbateman/webpack-visualizer: Visualize your Webpack bundle
GPUアクセラレーターが使える環境で強制的に有効にできるCSSの指定方法 :: 5509
ゼロから学ぶ「CSS Sprite」
