This repository has been archived on 2023-03-18. You can view files and clone it, but cannot push or open issues or pull requests.

Martin Brennan e15c86e8c5 DEV: Topic tracking state improvements (#13218) ... I merged this PR in yesterday, finally thinking this was done https://github.com/discourse/discourse/pull/12958 but then a wild performance regression occurred. These are the problem methods: 1aa20bd681/app/serializers/topic_tracking_state_serializer.rb (L13-L21) Turns out date comparison is super expensive on the backend _as well as_ the frontend. The fix was to just move the `treat_as_new_topic_start_date` into the SQL query rather than using the slower `UserOption#treat_as_new_topic_start_date` method in ruby. After this change, 1% of the total time is spent with the `created_in_new_period` comparison instead of ~20%. ---- History: Original PR which had to be reverted **https://github.com/discourse/discourse/pull/12555**. See the description there for what this PR is achieving, plus below. The issue with the original PR is addressed in 92ef54f402 If you went to the `x unread` link for a tag Chrome would freeze up and possibly crash, or eventually unfreeze after nearly 10 mins. Other routes for unread/new were similarly slow. From profiling the issue was the `sync` function of `topic-tracking-state.js`, which calls down to `isNew` which in turn calls `moment`, a change I had made in the PR above. The time it takes locally with ~1400 topics in the tracking state is 2.3 seconds. To solve this issue, I have moved these calculations for "created in new period" and "unread not too old" into the tracking state serializer. When I was looking at the profiler I also noticed this issue which was just compounding the problem. Every time we modify topic tracking state we recalculate the sidebar tracking/everything/tag counts. However this calls `forEachTracked` and `countTags` which can be quite expensive as they go through the whole tracking state (and were also calling the removed moment functions). I added some logs and this was being called 30 times when navigating to a new /unread route because `sync` is being called from `build-topic-route` (one for each topic loaded due to pagination). So I just added a debounce here and it makes things even faster. Finally, I changed topic tracking state to use a Map so our counts of the state keys is faster (Maps have .size whereas objects you have to do Object.keys(obj) which is O(n).) <!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->		2021-06-02 09:06:29 +10:00
..
acceptance	FIX: Maintain notification order by priority (#13186)	2021-05-31 09:27:13 +03:00
fixtures	FIX: Don't store translated trust level names in anonymous cache (#13224)	2021-06-01 22:11:48 +02:00
helpers	DEV: Topic tracking state improvements (#13218)	2021-06-02 09:06:29 +10:00
integration	DEV: Topic tracking state improvements (#13218)	2021-06-02 09:06:29 +10:00
unit	DEV: Topic tracking state improvements (#13218)	2021-06-02 09:06:29 +10:00
core_plugins_tests.js	FEATURE: Allow theme tests to be run in production (take 2) (#12845)	2021-04-28 23:12:08 +03:00
index.html	Support for Testem in Ember CLI (#12442)	2021-03-19 09:32:46 -04:00
plugin_tests.js.erb	FIX: Load .js files from plugins in qunit testing env (#11304)	2020-12-03 10:25:42 -06:00
setup-tests.js	DEV: Correct typos and spelling mistakes (#12812)	2021-05-21 11:43:47 +10:00
test_helper.js	FEATURE: Allow theme tests to be run in production (take 2) (#12845)	2021-04-28 23:12:08 +03:00
test_starter.js	FEATURE: Introduce theme/component QUnit tests (take 2) (#12661)	2021-04-12 15:02:58 +03:00
test-helper.js	DEV: Make dockcontainer and hidepassed the defaults (#12416)	2021-03-16 14:34:59 -04:00
theme_qunit_helper.js	DEV: Arrange theme QUnit dependencies in the right order (#12907)	2021-04-30 13:28:33 +03:00
theme_qunit_vendor.js	DEV: Arrange theme QUnit dependencies in the right order (#12907)	2021-04-30 13:28:33 +03:00