ブラウザレンダリング入門〜知ることで見える世界〜 - Qiita
はじめに 『レンダリングの仕組みなんて知らなくても、ブラウザが勝手にやってくれるじゃん！』 当時駆け出しのエンジニアだった私はそう思っていました。 実際、当時の私はレンダリングの『レ』の字も知りませんでしたが、特に業務上で問題はありませんでした。 しかし、その時は突然訪れました。 クライアントの要望でアニメーションを多彩に取り入れた案件を実装した際に、テスト段階で一部ブラウザ（S○f○ri、E○ge）でアニメーションがひどい状況になっていることが発覚しました。 (開発中はChromeで確認を行っており、Chromeでは特に問題はなかったので発覚が遅れました。) それからは、狂ったようにパフォーマンスの改善方法をググり、修正する日々が続きました。（最終的には、なんとかマルチブラウザでの動作も担保し、納品まで完了しました。） その案件が落ち着いた後、改めて自分の調べたことを振り返ると、局所的な
2017年度版 細かすぎて伝わらないJavaScriptの速度の話 - Qiita
概要 コードを書いていると誰もが気になってくる「どっちのほうがパフォーマンスに優れているの？」で、眠れない日々を過ごす人達のために、比較結果をまとめてみました。 実行環境 OS: macOS Sierra 10.12.5 Chrome: 58.0.3029.110 (64-bit) Safari: 10.1.1 計測方法 10 回実行した結果の平均値です。 比較 シングルクオート VS ダブルクオート コード start = () => { const retryCount = 1000000; const startTime = new Date(); for (let i = 0; i < retryCount; i = i + 1) { /* ダブルクオート const text = "abcde" + "fghij" + "klmno" + "pqrst" + "uvwxy" +
大規模プロダクトにおけるフロントエンドの1年間の変化 - Qiita
プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か
Linuxパフォーマンス調査などで使うコマンドメモ - Qiita
パフォーマンスなどの調査をする時に利用する便利コマンドメモ。 これないぞ、あれないぞなどあると思いますがとりあえず本などを参考にまとめたものをピックアップしています。 参考 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 絵で見てわかるシステムパフォーマンスの仕組み CPU使用率やメモリなど全体の概要把握 top デフォルトでは3秒ごとにOSで利用しているプロセスの数や状態、またOS全体のシステムリソース状況が分かります。 パフォーマンスが悪い場合にOS全体としてどのリソースの利用が多いのか(CPU負荷なのかメモリ利用率が高いのか)などの判断に有用だと思われます。 top - 22:36:56 up 28 min, 2 users, load average: 0.00, 0.02, 0.
オスプレイの熊本派遣はやはり不要。自衛隊ヘリ270機中65機（4分の1未満）しか派遣せず、と政府答弁書。 - Everyone says I love you !
ヘリコプターなら、どれでも垂直離陸するのでは？ これまで２回、米海兵隊のオスプレイをわざわざフィリピンから持ってきたのは熊本大地震の政治利用だと書いてきましたが、社民党の照屋寛徳衆院議員の質問主意書に対する政府の答弁書が閣議決定され、さらに、オスプレイ押しの政治利用だったことがはっきりしました。 この政府の答弁書によると、２０１６年３月末時点で、九州に所在する自衛隊の輸送機と陸自の多用途機は回転翼機（ヘリコプター）が約４０機あり、九州以外では固定翼機は約４０機、回転翼機は約２３０機あったということです。 オスプレイが初めて災害支援に参加した４月１８日の前日の１７日時点で派遣された自衛隊輸送機は、九州所在の回転翼２３機で、九州以外は固定翼９機、回転翼４２機でした。全国では計７４機となります。 つまり、九州所在のヘリでも４０機中２３機と半分強しか使っていないし、九州以外のヘリコプターは２３０機
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog;
最近フロントエンドの速度改善をほんの少しだけやって、いろんな資料を参考にしたので、今後また速度改善をする時に備えて、参考になった資料をまとめておく。今回パフォーマンス改善やった項目としてはExpiresヘッダ付ける、gzip圧縮かける、JSをbodyの一番下にとか基本的なことしかやらなかったので、そのあたりはこの記事ではまとめていません。 今回は「測定する」「ブラウザがどう表示しているか知る」「改善を検討する」の流れで調べていったのでその順にまとめる。 測定する 何はともあれ測定しないと何も始まらないので、まずは測定の仕方について調べた。 PageSpeed Insights( https://developers.google.com/speed/pagespeed/insights/ )と、webpagetest( http://www.webpagetest.org/ ) はとりあえ
サムスン製「A9」がTSMC製より電力を消費する理由
iPhone 6s・6s Plusのバッテリーの性能が、搭載されているチップ「Apple A9」のメーカーによって差があることが話題になっています。 「A9」はSamsung�とTSMCが供給していますが、Appleも”性能に2〜3%の違い“が存在することを認めており、その要因はチップの「製造プロセスルール」が、 サムスン製 ：14nm TSMC�製 ：16nm と異なることにあるようです。 下の動画をはじめ、様々な比較テストが行われていますが、概ね次のような傾向がみられるようです： プロセッサーのベンチマークに差はない(僅かにサムスン版が優勢？) サムスン版は連続して高負荷かけるとバッテリーをより多く消費する サムスン版は連続して高負荷かけると本体の温度がより高くなる 通常の負荷ではバッテリー・温度に差はみられない 単純に考えると、プロセスルールがより微細な14nm(サムスン製)の方が、
vmstatコマンドで覚えておきたい使い方8個(+1個) | 俺的備忘録 〜なんかいろいろ〜
LinuxやUNIXでパフォーマンスを監視する際にはお約束とも言えるvmstatコマンド。 どの現場でもよく使われるものだが、今回はこのコマンドで覚えておきたい使い方を紹介する。 なお、この内容はCentOS 7にてバンドルされている「procps-ng 3.3.9」のバージョンのものを用いている。 1.基本的な使い方 オプション無しで実行すると、以下のように現時点でのパフォーマンス情報が出力される。 vmstat [root@test-centos7 ~]# vmstat procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 80556 128 13915
MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSのパフォーマンスをお手軽に解析する方法 - Qiita