1. 02 Apr, 2020 1 commit
  2. 27 Mar, 2020 1 commit
  3. 26 Mar, 2020 1 commit
  4. 25 Mar, 2020 1 commit
  5. 24 Mar, 2020 1 commit
  6. 23 Mar, 2020 1 commit
  7. 22 Mar, 2020 1 commit
  8. 11 Mar, 2020 1 commit
  9. 02 Mar, 2020 1 commit
  10. 18 Feb, 2020 1 commit
  11. 14 Feb, 2020 1 commit
  12. 07 Feb, 2020 1 commit
  13. 02 Feb, 2020 1 commit
  14. 29 Jan, 2020 1 commit
  15. 24 Jan, 2020 1 commit
  16. 22 Jan, 2020 1 commit
  17. 20 Jan, 2020 1 commit
  18. 17 Dec, 2019 1 commit
  19. 26 Nov, 2019 1 commit
  20. 04 Nov, 2019 1 commit
  21. 16 Oct, 2019 1 commit
  22. 01 Oct, 2019 2 commits
  23. 30 Sep, 2019 3 commits
  24. 27 Sep, 2019 2 commits
  25. 23 Sep, 2019 1 commit
  26. 10 Sep, 2019 1 commit
    • rinpatch's avatar
      Revert "Parallelize template rendering" · 43f02dfe
      rinpatch authored
      This reverts commit 1ad71592.
      
      Since it had no limit on the number on concurrent processes it OOM killed
      instances while rendering hellthreads. When I tried introducing a
      concurrency limit with Task.async_stream/manual folds it lead to about 3 times
      worse performance on threads larger than 1000 activities (we are talking
      30s vs 1.2 minutes), I think this is not worth the about 1.5 times
      performance increase on smaller threads when using it.
      43f02dfe
  27. 07 Sep, 2019 1 commit
  28. 05 Sep, 2019 1 commit
  29. 04 Sep, 2019 1 commit
  30. 15 Aug, 2019 1 commit
  31. 13 Aug, 2019 1 commit
    • rinpatch's avatar
      Mastodon API: Preloading and normalization optimizations · c1b6952d
      rinpatch authored
      - Try to normalize the activity instead of object wherever possible
      - Put the `user` key on non-home timelines as well so bookmarks and
      thread mutes are preloaded there as well
      - Skip trying to get the user when rendering mentions if the id ==
      as:Public or user's follower collection
      - Preload the object when getting replied to activities and do not crash
      if it's not present
      
      This almost solves the problem of Pleroma hammering the db with a lot
      of queries when rendering timelines, the things left are
      1. When rendering mentions and the user is not in cache, save it for
      later and request all uncached users in one go
      2. Somehow get rid of needing to get the latest follow activity to
      detect the value of `requested` in a relationship. (create a database
      view for user relationship and cache it maybe?)
      c1b6952d
  32. 10 Aug, 2019 1 commit
  33. 31 Jul, 2019 1 commit
  34. 24 Jul, 2019 3 commits