1. 19 10月, 2014 5 次提交
  2. 18 10月, 2014 1 次提交
    • C
      Replace (slower) block.call with (faster) yield · 6aa115e4
      claudiob 提交于
      Performance optimization: `yield` with an implicit `block` is faster than `block.call`.
      See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark:
      
      ```ruby
      require 'benchmark/ips'
      
      def fast
       yield
      end
      
      def slow(&block)
       block.call
      end
      
      Benchmark.ips do |x|
       x.report('fast') { fast{} }
       x.report('slow') { slow{} }
      end
      
      # => fast    154095 i/100ms
      # => slow     71454 i/100ms
      # =>
      # => fast  7511067.8 (±5.0%) i/s -   37445085 in   4.999660s
      # => slow  1227576.9 (±6.8%) i/s -    6145044 in   5.028356s
      ```
      6aa115e4
  3. 17 10月, 2014 2 次提交
  4. 16 10月, 2014 5 次提交
  5. 14 10月, 2014 1 次提交
  6. 13 10月, 2014 3 次提交
  7. 01 10月, 2014 1 次提交
  8. 28 9月, 2014 2 次提交
    • A
      correct filename for jobs tests · 175ca453
      Abdelkader Boudih 提交于
      175ca453
    • R
      Follow up to #16613 · 1fac7b79
      Robin Dupret 提交于
      Since we want this flag to be enabled anytime we are running the tests
      under JRuby, let's enable this at the Rakefile level so people get the
      performance boost on their local checkout.
      
      Moreover, we avoid having to update this particular line anytime the
      option changes on the JRuby side.
      
      The only drawback is that we have to define it in every Rakefile but
      there's no big deal, this is already the case for other options.
      1fac7b79
  9. 27 9月, 2014 2 次提交
    • R
      Move object allocation out of loop · dfbcfafd
      Richard Schneeman 提交于
      Right now BenchmarkCleaner allocates hundreds of strings on every request with an exception. This patch moves those strings to be generated at boot once and re-used.
      
      ## Bench Methods
      
      I took a modified form of CodeTriage https://github.com/schneems/codetriage-ko1-test-app/blob/master/perf.rake and ran given rake tasks with and without the patch to BacktraceCleaner.
      
      I made an endpoint results in exception
      
      ```
        def index
          raise “foo"
        end
      ```
      
      The gem `memory_profiler` was used to capture objects allocated for a single request. Then `benchmark/ips` was used to test the speed of the patch.
      
      You will see that we use less objects and the code becomes measurably faster with this patch.
      
      ## With patch:
      
      Memory for one request:
      
      ```
      Total allocated 7441
      Total retained 37
      ```
      
      Requests per second:
      
      
      ```
      Calculating -------------------------------------
                       ips         4 i/100ms
      -------------------------------------------------
                       ips       43.0 (±4.7%) i/s -        216 in   5.037733s
      ```
      
      
      ## Without patch:
      
      Memory used for one request:
      
      
      ```
      Total allocated 11599
      Total retained 35 
      ```
      
      Requests per second:
      
      ```
      Calculating -------------------------------------
                       ips         3 i/100ms
      -------------------------------------------------
                       ips       39.4 (±7.6%) i/s -        198 in   5.052783s
      ```
      
      ## Analysis
      
      The patch is faster:
      
      ```
      (43.0 - 39.4 ) / 39.4 * 100
      # => 9 # % ~ speed bump
      ```
      
      It also allocates less objects:
      
      ```
      11599 - 7441
      # => 4158
      ```
      
      These strings are allocated on __EVERY SINGLE REQUEST__. This patch saves us 4158 objects __PER REQUEST__ with exception.
      
      Faster errors == Faster applications
      dfbcfafd
    • R
      Preparing for 4.2.0.beta2 release · 4581d044
      Rafael Mendonça França 提交于
      4581d044
  10. 26 9月, 2014 5 次提交
  11. 25 9月, 2014 2 次提交
  12. 24 9月, 2014 1 次提交
  13. 23 9月, 2014 1 次提交
  14. 22 9月, 2014 2 次提交
  15. 20 9月, 2014 1 次提交
  16. 19 9月, 2014 1 次提交
    • X
      inject Rack::Lock if config.eager_load is false · 112077c2
      Xavier Noria 提交于
      If code is not eager loaded constants are loaded on demand. Constant
      autoloading is not thread-safe, so if eager loading is not enabled
      multi-threading should not be allowed.
      
      This showed up in certain Capybara scenarios: Most Capybara drivers
      other than Rack::Test need a web server. In particular, drivers for
      JavaScript support. Capybara launches WEBrick in its own thread for
      those but that per se is fine, because the spec thread and the server
      thread are coordinated.
      
      Problem comes if the page being served in the spec makes Ajax calls.
      Those may hit WEBrick in parallel, and since WEBrick is multi-threaded
      and allow_concurrency? returns true in the test environment before
      this patch, threads are spawned to serve those parallel requests. On
      the other hand, since eager_load is false by default in the test
      environment, constants are not preloaded.
      
      So the suite is autoloading constants in a multi-threaded set. That's
      a receipt for paracetamol. The symptom is random obscure errors whose
      messages point somehow to constant autoloading.
      
      As a consequence of this fix for allow_concurrency? WEBrick in
      Capybara scenarios no longer runs in multi-threaded mode.
      
      Fixes #15089.
      112077c2
  17. 17 9月, 2014 2 次提交
  18. 15 9月, 2014 2 次提交
  19. 13 9月, 2014 1 次提交