タグ

performanceに関するrydotのブックマーク (13)

  • シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました! ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ

    あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ?」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ???」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム

    シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました! ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
  • Mackerelにおけるフロントエンドのパフォーマンス改善の取り組み - Hatena Developer Blog

    この記事は、はてなエンジニアアドベントカレンダー2016の14日目の記事です。13日は id:astj による『Perl 6 のモジュールエコシステムの話とモジュールを公開する話 (2016年12月版) - 平常運転』でした。 こんにちは。Mackerelチームでアプリケーションエンジニアをやっている id:itchyny です。 Mackerelは、同じ役割を持つホストを束ねた「ロール」、そしてロールを束ねた「サービス」というまとまりでホストを管理し、一覧性の良いグラフ画面を提供しています。 ロールあたりのホスト数、そしてサービスあたりのロール数が増えると、グラフの画面のパフォーマンスに大きく影響します。 Mackerelチームでは大規模なサービスでも快適にグラフを閲覧できるように、継続的に画面のパフォーマンスを改善してきました。 記事では、Mackerelフロントエンドのパフォーマ

    Mackerelにおけるフロントエンドのパフォーマンス改善の取り組み - Hatena Developer Blog
  • 高速なハッシュテーブルを設計する | POSTD

    (訳注:2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) はじめに 稿では、高速で汎用的なハッシュテーブルを作るために行う、設計についての多くの意思決定事項を紹介します。最終的に、私の emilib::HashSet とC++11の std::unordered_set の間のベンチマークが出来上がりました。もし、ハッシュテーブルに興味があって、自分で設計したいなら(どのプログラミング言語かに関わらず)、稿がヒントになるかもしれません。 ハッシュテーブル は、素晴らしい発明です。 ならし計算量O(1) ( O(√N)時間 )で、挿入、削除、検索を行うことができます。ならし計算量とは、ハッシュテーブルの計算に平均でO(1)の計算量がかかることを意味しますが、時々、これよりも多くの時間がかかる場合があります。具体的には、ハッシュテーブルに空きがない場合で、挿入の

    高速なハッシュテーブルを設計する | POSTD
  • プロファイラは本当に必須か?―パフォーマンスについて考える | POSTD

    最近、2つの出来事があり、私が行っているパフォーマンスへのアプローチ方法は、あまり広く知られていないようだと感じさせられました。 1つ目の出来事は、 redditでBufferBuilderを発表 した際に、初期のコメントで次のような質問をもらったことです。「Haskellを実行する時に、プロファイラを利用してコードのどの部分で処理が遅くなっているのか確認しましたか?」というものでした。もっともな質問ですが、私の答えは”ノー”でした。プロファイラは利用していません。なぜなら、Haskellのプロファイラで確認できる段階では既に遅すぎるからです。私はバッファを構築する効率的な方法を既に知っていました。境界チェックをしてから、保存(シングルバイトの場合)または複製(バイト列の場合)をするやり方です。これ以上の命令は意味がありません。ですから、BufferBuilderの開発にあたって最初にやっ

    プロファイラは本当に必須か?―パフォーマンスについて考える | POSTD
  • ActiveRecordを速くしたいだけの人生だった - Qiita

    Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを

    ActiveRecordを速くしたいだけの人生だった - Qiita
  • 「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? - mizchi's blog

    CoffeeScriptの関数は明示的にreturnするべき | CreativeStyle 当に遅いのか、それを確かめましょう。 適当にでっちあげたコードです f1 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j f2 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j return console.time "f1" for i in [1..100000] then f1() console.timeEnd "f1" console.time "f2" for i in [1..100000] then f2() console.timeEnd "f2" 実行してみます $ coffee hoge.coffee f1: 105ms f2: 4ms 約26倍違う、ということがわかります。

    「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? - mizchi's blog
  • Haskellの神話 - あどけない話

    Haskell の優雅さを示すためによく使われるコードは、優雅さと分かりやすさだけに特化しており、現実的には遅いことが多い。書き手は他に効率のよい実装があることを知っているのだけれど、読み手はそうではないから、後で効率が悪いと気づいて愕然とするみたいだ。 この記事では、神話になっている例を3つ取り上げ、効率のよい実装と合わせて紹介する。その 3 つの例とは、以下の通り。 フィボナッチ数 素数生成 ソート フィボナッチ数 遅延評価を活かした優雅なフィボナッチ数の実装は、以下の通り。 fib n = fibs !! n fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅いにも書かれているように、この実装は遅い。 その理由は、(+) の計算が遅延し、その待機

    Haskellの神話 - あどけない話
  • jstolarek.com

    This domain may be for sale!

  • Overview - Process Hacker

    Process Hacker A free, powerful, multi-purpose tool that helps you monitor system resources, debug software and detect malware. Graphs and statistics allow you quickly to track down resource hogs and runaway processes. Use Ctrl+I to view system performance information. Move your cursor over a graph to get a tooltip with information about the data point under your cursor. You can double-click the g

  • Haskellコードの高速化

    Haskellで速いコードを書くためのヒントを無秩序に集積したもの。環境としてはGHCを想定する。私は高速化について詳しい訳ではないが、思い付いたことはなんでもかんでも書くように心がけたので、運が良ければ何か役に立つ情報があるかもしれない。 並列処理のパフォーマンスについてはこの文章では触れない。まったく経験がないので。同じ理由で、浮動小数点数を多用した数値計算コードの効率化と、書き換え規則を多用する高水準の最適化も扱わない。 お願い: 文中に間違いや分かりにくい部分があれば指摘いただけると有難いです。また、他に載せた方が良さそうな最適化テクニックや、その他の改善提案があれば教えてください。掲示板またはメールまたはTwitter(@mkotha)までお願いします。 目次 基的なこと 遅延評価の計算量見積もりの方法と、GHCの内部に依存しないテクニック集。入門書を読んだけれども、Haske

  • YouTube - Formant Brothers "Ordering a Pizza de Brothers!"

    「兄弟deピザ注文」(2003) by フォルマント兄弟 人類初。リアルタイムに鍵盤演奏し、人工音声でピザ注文。 The documentation of a live performance by Formant Brothers (Masahiro Miwa & Nobuyasu Sakonda) recorded in Osaka/Japan in Nov. 2003. see also http://formantbros.jp/ --- In Ordering a Pizza de Brothers! the Formant Brothers perform music on their own real-time voice synthesis system, the Klavocode, and as a side-effect of this

    YouTube - Formant Brothers "Ordering a Pizza de Brothers!"
  • WebGL Path Tracing

    Path tracing is a realistic lighting algorithm that simulates light bouncing around a scene.  This path tracer uses WebGL for realtime performance and supports diffuse, mirrored, and glossy surfaces.  The path tracer is continually rendering, so the scene will start off grainy and become smoother over time.  Here's how to interact with it: Add an object using the "Add Sphere" or "Add Cube" buttons

  • 予定外 Visual C++ Express Editionでプロファイラを使ってみる

    [PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 ソフト開発の技術書には、パフォーマンス最適化について書かれているものも多いですが、そこで必ずと言っていいくらいに述べられているのが、「コードを書く時点から最適化をしない」「手を加える前にまずパフォーマンスを測定せよ」ということです。 「プログラムの処理にかかる時間の80%はコード全体の20%の部分が占める」という、いわゆるパレートの法則に則り、まず測定によってプログラムの実行時間の大半を占めるわずかな部分のコードを割り出して、そこを集中的に改善しましょう、というのが定説です。 コードの測定には通常、プロファイラと呼ばれるツールを使います。 プロファイラは、どの関数がどのくらいの時間実行されていたか、何回呼び出されたかなどの方法を収集して解析し、ボトルネックとなっている部分を探すこ

  • 1