1. 11 8月, 2016 2 次提交
  2. 10 8月, 2016 3 次提交
  3. 09 8月, 2016 6 次提交
  4. 08 8月, 2016 3 次提交
    • J
      f04e9dad
    • Y
      Added concern for a faster "cache_key" method · 77c8520e
      Yorick Peterse 提交于
      This concern provides an optimized/simplified version of the "cache_key"
      method. This method is about 9 times faster than the default "cache_key"
      method.
      
      The produced cache keys _are_ different from the previous ones but this
      is worth the performance improvement. To showcase this I set up a
      benchmark (using benchmark-ips) that compares FasterCacheKeys#cache_key
      with the regular cache_key. The output of this benchmark was:
      
          Calculating -------------------------------------
                     cache_key     4.825k i/100ms
                cache_key_fast    21.723k i/100ms
          -------------------------------------------------
                     cache_key     59.422k (± 7.2%) i/s -    299.150k
                cache_key_fast    543.243k (± 9.2%) i/s -      2.694M
      
          Comparison:
                cache_key_fast:   543243.4 i/s
                     cache_key:    59422.0 i/s - 9.14x slower
      
      To see the impact on real code I applied these changes and benchmarked
      Issue#referenced_merge_requests. For an issue referencing 10 merge
      requests these changes shaved off between 40 and 60 milliseconds.
      77c8520e
    • J
  5. 06 8月, 2016 3 次提交
  6. 05 8月, 2016 5 次提交
  7. 04 8月, 2016 15 次提交
  8. 03 8月, 2016 3 次提交
    • Y
      Instrument Gitlab::Highlight · 9a934e25
      Yorick Peterse 提交于
      This class does quite a few interesting things so let's instrument it so
      we can see how much time is being spent in this class.
      9a934e25
    • Y
      Improve performance of SyntaxHighlightFilter · 038d6feb
      Yorick Peterse 提交于
      By using Rouge::Lexer.find instead of find_fancy() and memoizing the
      HTML formatter we can speed up the highlighting process by between 1.7
      and 1.8 times (at least when measured using synthetic benchmarks). To
      measure this I used the following benchmark:
      
          require 'benchmark/ips'
      
          input = ''
      
          Dir['./app/controllers/**/*.rb'].each do |controller|
            input << <<-EOF
            <pre><code class="ruby">#{File.read(controller).strip}</code></pre>
      
            EOF
          end
      
          document = Nokogiri::HTML.fragment(input)
          filter = Banzai::Filter::SyntaxHighlightFilter.new(document)
      
          puts "Input size: #{(input.bytesize.to_f / 1024).round(2)} KB"
      
          Benchmark.ips do |bench|
            bench.report 'call' do
              filter.call
            end
          end
      
      This benchmark produces 250 KB of input. Before these changes the timing
      output would be as follows:
      
          Calculating -------------------------------------
                          call     1.000  i/100ms
          -------------------------------------------------
                          call     22.439  (±35.7%) i/s -     93.000
      
      After these changes the output instead is as follows:
      
      Calculating -------------------------------------
                      call     1.000  i/100ms
      -------------------------------------------------
                      call     41.283  (±38.8%) i/s -    148.000
      
      Note that due to the fairly high standard deviation and this being a
      synthetic benchmark it's entirely possible the real-world improvements
      are smaller.
      038d6feb
    • S
      Store all secret keys in secrets.yml · 379c2cbc
      Sean McGivern 提交于
      Move the last secret from .secret to config/secrets.yml, and delete
      .secret if it exists.
      379c2cbc