On Tue, Jul 07 2026, "Patrice CHOTARD" <[email protected]> wrote:
> On 7/6/26 18:00, Marek Vasut wrote: >> On 7/6/26 5:16 PM, Patrice CHOTARD wrote: >> >> Hello Patrice, >> >>>>> I did a test, it doesn't bring any noticeable improvements, but >>>>> nevertheless i will submit a v3 with this update. >>>> >>>> Does the list iteration exit when it finds the first entry that is not >>>> going to be executed at this time ? If it does not, then there will be no >>>> improvement. But for this to work, the list would have to be surely fully >>>> ordered in incrementing timestamp order, is it ? >>> >>> No, the list iteration parse all entries. >>> >>> I see your point, on original implementation, entries are not sort by >>> incrementing timestamp order. >>> I did some implementation test, by sorting cyclic entries in cyclic_list >>> when : >>> _ registering a new cyclic callback, put it directly in the right >>> position in cyclic_list. >>> _ in cyclic_run(), after running a cyclic, compute its next call and >>> insrt it in the right position in cyclic_list. >>> >>> There is no noticeable gain. >> >> Did you also break from the iteration when you reached the first entry with >> future timestamp ? That might actually help. >> > > In cyclic_run(), as now entries was sorted by increasing timestamp, only the > first cyclic in cyclic_list is parsed, > we don't need to parse all cyclic_list element. > The point is kind of moot as v3 seems to work just as well, but I do want to point out that no, ensuring that the first expiring timer is at the front does not _sort_ the list, and breaking once we hit the first non-expired timer would be wrong. It would of course work for a list with at most two elements, but not in general. Rasmus
