Add timings back with a native event

[JIBSIL]

Problem

I was really unhappy with Skript a few weeks ago, when badly coded scripts were lagging my server to 15-17 TPS on 25 players. It was really frustrating not to have Timings, after it was deprecated. Spark is entirely useless for Skript and I needed a better way to profile events.

Solution

I added a native profile API with Profile events which run automatically when code is triggered. It's as lightweight or even more lightweight than timings. I added a new event on profile available so that users can see how long their events took. Also, I improved trigger debug verbosity by adding more information like expression and full Skript path in the trigger debugs, so that setting verbosity to debug in the Skript options displays more useful output.

Here is the minimum usable code to test my changes:

on profile complete:
	broadcast "%event-string% took %event-number%ms"

This is the script that I use on my server that allows to view these in a fully featured way
https://gist.github.com/JIBSIL/c117f881a88e9c28568b89b2f4bb7f7a

Testing Completed

All tests were passed with the gradlew skriptTest command.

Supporting Information

I couldn't get it to be event-duration or something more descriptive in on profile complete, I would appreciate help with that if it's going to be merged. Also, maybe the ProfilerAPI or the Profile events should be public, I don't know Skript's policy on exposing those kinds of APIs so I left them private for now.

[sovdeeth]

seems like a decent start for a profiling api
i'm not sure a single timer should be called a profiler, though. Usually a profiler will track multiple execution times and collate them for easy usage rather than just a single execution time. It may be preferable for a user to be able to start a profiler, any executions while it's active are added to that profiler, then be able to stop it and query it for information. Basically what spark does, or what your script does, but built in.

I'm mainly worried that event will be called a tremendous number of times and cause significant slowdown.

[sovdeeth]

i'm not so sure about this design for checking if a trigger is in a profiler event. If the thread changes at all (see skript-reflect or skbee async sections), won't it be unreliable?

[EquipableMC]

You should also be targeting dev/feature and use dev/feature, rather than master. Just an fyi. Maybe someone from skriptlang can fix this?

[erenkarakal]

what happens if 2 triggers from different threads run at the same time?

[erenkarakal]

You should also be targeting dev/feature and use dev/feature, rather than master. Just an fyi. Maybe someone from skriptlang can fix this?

needs rebasing

[EquipableMC]

You should also be targeting dev/feature and use dev/feature, rather than master. Just an fyi. Maybe someone from skriptlang can fix this?

needs rebasing

Gotcha. @JIBSIL just so you're aware ^^ ❤️

[Absolutionism]

As Sovde mentioned with the potential of this being called multiple times, we should probably not be doing profilers for ProfileCompletedEvent. In my opinion at least.

[sovdeeth]

need to resolve conflicts (also remember to click re-request when you've completed someone's requested changes)