Replace Timings with Spark

[kashike]

Based on an internal discussion in August of 2022, we are now entering the planning stages to remove the Timings functionality from the Paper server software, and to include Spark in the distribution instead. More information will be shared once plans have solidified, this issue is being opened now to begin public tracking of our plans.

Some of the reasons for this are as follows:

• Timings has been unmaintained for multiple years now, with only very few additional timings categories added since. Because of this, it is not ideal for actually identifying causes of lag in specific plugins or parts of the server outside of simple categories like synchronous chunk loads.
• Timings are difficult to read for people that are new to it, and there are no short and easy to digest tutorials on it either. Spark is a lot less confusing in terms of UI and has more beginner-friendly documentation.
• Enabling timings can sometimes have non-negligible hits on server performance, whereas Spark is lighter and also has an asynchronous profiling mode.

While all of this is still open for discussion, here are potential todos:

• Deprecate public Timings classes for removal #8949 ?
• Add runtime nags for uses of Timings API: 32875b4
• Figure out how exactly to bundle or include spark
• Make sure spark properly replaces the useful functionality timings had

[hendoulmou9]

Figure out how exactly to bundle or include spark: for example, we can create a new timing using Spark's Spark.createTask() method, which takes a string as a parameter representing the name of the timing task. We then start the timing using the startTiming() method, and run some code. Finally, we stop the timing using the stopTiming() method.

[Phoenix616]

I feel like one requirement for a replacement should be to have equally user-friendly names for entries like Timings has right now which is a major benefit of it over Spark: That someone who doesn't know anything about internals is able to quickly spot what is wrong and not have to bother data that doesn't matter for them.

Having just the (sometimes confusing or even wrong) Mojang names of classes/methods doesn't really help people that are not developers and right now Timing names also provide additional context like the type of entity or the default tick counts that are currently not accessible via Spark or (easy) other means.

• Timings are difficult to read for people that are new to it, and there are no short and easy to digest tutorials on it either. Spark is a lot less confusing in terms of UI and has more beginner-friendly documentation.

Basically I'm counteracting this point. Spark profile entries are a lot harder to read than timings entries are. Timings (in contrast to spark) even provides the parts that cause issues directly at the top as well as point out lag directly, something that Spark doesn't do (at least as far as I know)

If anything the Mojang profiler information (which is in places more granular than timings) should be used. (Or could even be pulled into timings directly to solve the "Timings has been unmaintained for mulitple years now" part)

Other requirements (besides better user-friendlieness/usability) for a new system that I see that Spark doesn't provide (right now):

• A way for plugins to specify human-readable names for stuff like Timings did would be really appreciated, a user is not going to understand what some loop/stream structure means but they can easily know that with plugin-author provided information
• Automatic pointing out stuff that causes lag (similar to Timings default lag view and the ordering of the entries by the time spent. Spark (by default) uses a tree view which you need to manually expand)
• Easily accessible Entity count information per region (Timings region tab, Spark has that information but the interface there right now is really convoluted and hard to use)

[regulad]

You should consider contributing to Spark to bring it closer to feature parity with Timings, as the Timings library has been unmaintaned for quite some time now (see OC issue) and only becomes more archaic and harder to work with as time goes on. Spark, on the other hand, is still being actively maintained and having features added. Other Paper forks like Pufferfish/Purpur have already replaced their timings with Spark, and do not seem to have lost any functionality or ease-of-use.

[Phoenix616]

@regulad I fail to see how your comment helps at all with the discussion how Spark can/should be included in Paper directly and how it compares to Timings. Of course if Spark should be used directly and changes need to be made to bring it up to the usability of Timings then that could be contributed directly to their project (although it would probably still be necessary to have some changes be done directly in the server and not just Spark alone, e.g. Spark would not be able to automatically know the context that their data is gathered from without markers directly in the server code indicating that in a human-readable way similar to how Timings work right now)