[Debug] Sort timeline elements by start and duration.

[sfadschm]

This PR implements a sorting algorithm to the elements of the debug toolbar timeline.
Such sorting seems to be intended (and is useful) but has likely been forgotten:

CodeIgniter4/system/Debug/Toolbar.php

Lines 247 to 249 in e73f750

	// Sort it
	return $data;

In principle, many of the elements are pre-sorted by nature, but chaos grows when multiple collectors are active (e.g. from Modules etc.).

I decided to sort the elements ascending by start time and then descending by duration time.
I.e., if a timed portion of code calls another timed portion of code and the timer start times happen to be equal (possibly unlikely, but just in case), the "outer" timer will be displayed first in the timeline.

This sorting also prepares for a possible "collapsible" timeline, which I need to think about how to realize.

Open for other opinions/ideas 😄

Forum link for discussion.

Timeline before changes:

Timeline after changes:

Note that due to the styling of the single timeline elements (a left-right-padding of 5px), some very small elements appear to still be shifted on the first glance, but they're not if one puts a ruler on it 😆

Checklist:

• Securely signed commits
• Component(s) with PHPdocs
• Conforms to style guide

[paulbalandan]

I like the "after" changes as I think this is what a timeline should be, ...chronologically sorted. I'm just wondering though why there are gaps in between as I expected this to be like a Gantt chart with more or less overlapping bars. Does that mean not all places in the booting are timed?

[sfadschm]

I'm just wondering though why there are gaps in between

Was wondering the same. I have to check. Might be some 'pre_system' events that I registered.

Gantt chart with more or less overlapping bars.

In principle the bars would not overlap at all. The styling however applies a horizontal padding of 2*5px to achieve the 4px border-radius.

[paulbalandan]

Well, yes, I mean not technically overlapping. But the end of one bar is aligned with the start of the next bar on the next line.

[sfadschm]

In that case, yes 😄
I just checked, it's not the pre_system events, they're included in the bootstrap timer.
In my case, it is the before filters in handleRequest()

[paulbalandan]

Can you target 4.2 instead?

[sfadschm]

Well, yeah, this went down the drain 😆

[sfadschm]

Just for future reference: Is there a proper way to switch the target branch? Both switching it here in the PR and rebasing the local repo to 4.2 resulted in additional commits.

[paulbalandan]

I think you need to branch off first from 4.2 branch for your PR branch whenever it is for content changes.

[MGatner]

Probably beat to start over here. You want something like this (assuming you have your fork as origin and the main repo as upstream):

git fetch upstream
git switch -c sort-debugbar-timeline upstream/4.2