1. 20 Dec, 2017 1 commit
    • Camillo Bruni's avatar
      [tools] New parse processor tool · b0e2074d
      Camillo Bruni authored
      From the log data generated with --log-function-events we can create a
      detailed model of a function's lifetime. The parse processor displays
      several stats at a given time (percent and count) on a per function or
      byte basis:
      - preparsing
      - parsing
      - eager/lazy compiling
      - execution
      
      Bug: chromium:757467
      Change-Id: I0ad5c9369c6a0628704e3caffb3920444ea603a9
      Reviewed-on: https://chromium-review.googlesource.com/758641
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50234}
      b0e2074d
  2. 24 Oct, 2017 1 commit
  3. 20 Feb, 2017 1 commit
  4. 23 Aug, 2013 1 commit
  5. 26 Jul, 2012 1 commit
  6. 26 Sep, 2011 1 commit
  7. 05 Jul, 2011 1 commit
  8. 16 Mar, 2011 1 commit
  9. 08 Feb, 2010 1 commit
  10. 09 Jul, 2009 1 commit
  11. 07 Jul, 2009 2 commits
  12. 20 Jun, 2009 1 commit
  13. 18 Jun, 2009 1 commit
  14. 05 Jun, 2009 1 commit
  15. 20 May, 2009 1 commit
  16. 28 Apr, 2009 1 commit
  17. 27 Apr, 2009 1 commit
    • mikhail.naganov@gmail.com's avatar
      TickProcessor script reimplemented in JavaScript. · aa2c3312
      mikhail.naganov@gmail.com authored
      This is an effort to reuse profiler data processing code both in
      TickProcessor and Dev Tools Profiler. The old Python implementation
      will be removed.
      
      The new TickProcessor works almost identical to the previous one.
      However, it has some differences:
      
      1. Not very useful "Call profile" section is replaced with a new
         WebKit-like "Bottom up (heavy) profile" which shows the most
         expensive functions together with their callers. I used it
         personally in order to find and remove bottlenecks in the
         tickprocessor script itself, and found it quite helpful.
      
      2. Code entries with duplicate names (they occur for RegExes, stubs
         and sometimes for anonymous Function objects) are now distinguished
         by adding an occurence number inside curly brackets.
      
      3. (Address -> code entry) mapping is more precise in boundary cases.
      
      4. Windows version no more requires specifying .map file location.
      
      5. Works faster.
      
      Review URL: http://codereview.chromium.org/99054
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      aa2c3312