print(a,b)
print(a.." "..b) -- well, would need to be strings
DS:GetAsync(123)
DS:GetAsync("123")
Instance.new("Part")
Instance.new("Part",nil)
There’s even one method, iirc, that won’t error when doing f(1,nil) but errors for f(1)
TL;DR: Consistency doesn’t seem that important. (although it should be)
In the case of debug.profileend(String label = nil) it shouldn’t really matter anyway.
The consistency there is just part of your coding style.
This is just a huge opinion thing, I always like to just force specific API usage (to some degree).
I understand the value of making it optional too, but I do think the added value of forcing everyone to use a single style outweighs the case a few people have a slight preference for the other style in this case. I do have a preference for pretty much any “non-invasive” alternative (so both the original option 1 and my alternative would work fine for me), though. They barely differ in my opinion.
But the second close is right, it’s that first close that shouldn’t be there.
Only fix I can think of is also listing the location of all profileend()s since the last profilebegin()
debug.profilebegin("Wrap")
debug.profilebegin("A")
debug.profileend()
debug.profilebegin("B")
debug.profileend("B")
debug.profileend() -- This one is too much
debug.profileend()
-- erormessage for line 7 about calling profileend() too much
<stacktrace if that's still included>
Begin profile statistics
Start profiling "Wrap" at script 'Workspace.Script', Line 1
Start profiling "B" at script 'Workspace.Script', Line 4
Stop profiling "B" at script 'Workspace.Script', Line 5
Stop profiling at script 'Workspace.Script', Line 6
End profile statistics
“A” isn’t included, because “B” is on the same level, thus has overriden the history of A (and descendants).
The “Stop profiling” at ine 6 doesn’t include the label, as it wasn’t included as parameter. (and to see what it actually ended, you just need to look one Start up in the statistics anyway)
I get what you’re saying.
If you want this level of profile section debugging, you can just implement the “tokens” in lua.
(You’d have some sort of state stack, and increment this integer every time you call your profilebegin wrapper. When you call your profileend wrapper, you’d check that the value passed in is the same as the value at the top of the stack).
Nice videos! I think it’d be great if we could also have a wiki page for the profiler that included a list of common issues by name (e.g. “Physics”, “Present”, etc) and what they’re caused by (some may not be as self-explanatory as those two).
This is amazing. Now it’s so much easier to track what my changes do in-game. Before I had to spend like 10 seconds each time zooming in and in until I found a specific portion of a script. This is so useful!
This is kind of a picky bug, but its been around for awhile now, so I figured I should report this.
If you try to right click zoom on a profile frame that took 0.000 ms, ROBLOX Studio will hang itself, probably due to some divide by zero problem.
This can be replicated pretty easily if you call debug.profilebegin(“test”) and then immediately call debug.profileend() in a while loop.