-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Timings with Spark #8948
Comments
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. |
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.
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):
|
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. |
@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) |
Antivirus software is generally useless about jar files and often just flags stuff somewhat blindly at best. I don’t think that the malicious result from a singular piece of software stands for annything against an open source project in which you can vet every single line of code in the output. |
This comment was marked as spam.
This comment was marked as spam.
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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:
While all of this is still open for discussion, here are potential todos:
The text was updated successfully, but these errors were encountered: