BigW Consortium Gitlab

  1. 09 Aug, 2016 1 commit
  2. 08 Aug, 2016 1 commit
    • Added concern for a faster "cache_key" method · 77c8520e
      Yorick Peterse authored
      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.
  3. 29 Jul, 2016 1 commit
    • Method for returning issues readable by a user · 002ad215
      Yorick Peterse authored
      The method Ability.issues_readable_by_user takes a list of users and an
      optional user and returns an Array of issues readable by said user. This
      method in turn is used by
      Banzai::ReferenceParser::IssueParser#nodes_visible_to_user so this
      method no longer needs to get all the available abilities just to check
      if a user has the "read_issue" ability.
      
      To test this I benchmarked an issue with 222 comments on my development
      environment. Using these changes the time spent in nodes_visible_to_user
      was reduced from around 120 ms to around 40 ms.
  4. 12 Jul, 2016 1 commit
  5. 01 Jul, 2016 2 commits
  6. 30 Jun, 2016 1 commit
  7. 23 Jun, 2016 1 commit
    • Fix pagination on sorts with lots of ties · d7a5a28c
      Sean McGivern authored
      Postgres and MySQL don't guarantee that pagination with `LIMIT` and
      `OFFSET` will work if the ordering isn't unique. From the Postgres docs:
      
      > When using `LIMIT`, it is important to use an `ORDER BY` clause that
      > constrains the result rows into a unique order. Otherwise you will get
      > an unpredictable subset of the query's rows
      
      Before:
      
          [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
          [2] pry(main)> issues.count
          => 81
          [3] pry(main)> issues.uniq.count
          => 42
      
      After:
      
          [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
          [2] pry(main)> issues.count
          => 81
          [3] pry(main)> issues.uniq.count
          => 81
  8. 21 Jun, 2016 1 commit
  9. 16 Jun, 2016 2 commits
  10. 14 Jun, 2016 2 commits
  11. 13 Jun, 2016 1 commit
  12. 08 Jun, 2016 1 commit
    • Fix pseudo n+1 queries with Note and Note Authors in issuables APIs · fade1a4c
      Alejandro Rodríguez authored
      This was not a clear cut n+1 query, given that if you're directly subscribed to all issues
      that the API is returning you never really need to check for the notes. However, if you're
      subscribed to _all_ of them, then for each issuable you need to go once to `notes`, and
      once to `users` (for the authors). By preemtively loading notes and authors, at worst you have
      1 extra query, and at best you saved 2n extra queries. We also took advantage of this preloading
      of notes when counting user notes.
  13. 06 Jun, 2016 1 commit
  14. 03 Jun, 2016 2 commits
  15. 02 Jun, 2016 1 commit
    • issuable#labels_array explicitly load the labels · 078ba8c0
      Paco Guzman authored
      This will be useful when you want to ask for the 
      number of items and later iterate over them, without 
      needing to ask if the association is load or not.
      
      So you avoid extra database queries
  16. 01 Jun, 2016 1 commit
    • Refactor Participable · 580d2501
      Yorick Peterse authored
      There are several changes to this module:
      
      1. The use of an explicit stack in Participable#participants
      2. Proc behaviour has been changed
      3. Batch permissions checking
      
      == Explicit Stack
      
      Participable#participants no longer uses recursion to process "self" and
      all child objects, instead it uses an Array and processes objects in
      breadth-first order. This allows us to for example create a single
      Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
      a ReferenceExtractor removes the need for running potentially many SQL
      queries every time a Proc is called on a new object.
      
      == Proc Behaviour Changed
      
      Previously a Proc in Participable was expected to return an Array of
      User instances. This has been changed and instead it's now expected that
      a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
      value of the Proc is ignored.
      
      == Permissions Checking
      
      The method Participable#participants uses
      Ability.users_that_can_read_project to check if the returned users have
      access to the project of "self" _without_ running multiple SQL queries
      for every user.
  17. 31 May, 2016 1 commit
  18. 29 May, 2016 2 commits
  19. 24 May, 2016 5 commits
  20. 23 May, 2016 1 commit
  21. 12 May, 2016 2 commits
  22. 11 May, 2016 1 commit
  23. 10 May, 2016 1 commit
  24. 06 May, 2016 1 commit
  25. 27 Apr, 2016 1 commit
  26. 21 Apr, 2016 2 commits
  27. 20 Apr, 2016 3 commits