Improve optimistic_yield intervals for performance gain in sketches #7952
Conversation
dok-net
force-pushed
the
optimistic_yield_intervals
branch
2 times, most recently
from
58708b3
to
8b164cc
Compare
There was a problem hiding this comment.
As we discussed, I think the existing constants in optimistic_yield were chosen as a best-guess with no real "100% correct answer" possible. So I looked at the reasoning as to why the oy was there in the 1st place and how the change would affect it (considering expectation value of wait times for busywait loops).
dok-net
force-pushed
the
optimistic_yield_intervals
branch
2 times, most recently
from
afb2656
to
40cff9e
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
40cff9e
to
f3dbafc
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
f3dbafc
to
816c727
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
7 times, most recently
from
b903aa6
to
b8bd44b
Compare
| const uint32_t pulse_start_cycle_count = xthal_get_ccount(); | ||
| WAIT_FOR_PIN_STATE(!state); | ||
| if (!waitForPinState(pin, !state, timeout_cycles, start_cycle_count)) { | ||
| return 0; |
There was a problem hiding this comment.
This is wrong per my reading of the (not so hot docs) https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/?setlang=it
Return 0 on no pulse beginning edge detected. OTW, it should return the full timeout as the pulse width (i.e. get rid of the return 0 and just fallthru tho the return below).
There was a problem hiding this comment.
@earlephilhower I thought I had answered a long time before. IIRC I researched and besides this refactoring not changing how the return works before, my reading of the docs etc was that returning 0 was and is correct. Hm.
There was a problem hiding this comment.
@earlephilhower Can you agree this year; the change is just same effective execution path as with the macros before?
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
b8bd44b
to
da6c4e8
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
3 times, most recently
from
c2b436e
to
7fe3607
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
7fe3607
to
e58126f
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
2 times, most recently
from
dc76df9
to
e80a82b
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
e80a82b
to
65deed2
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
65deed2
to
5fe47c9
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
5fe47c9
to
c994b68
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
c994b68
to
ca07b3a
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
2 times, most recently
from
fbaebe3
to
bd32d2c
Compare
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
bd32d2c
to
1bf128f
Compare
10000µs for just-checking "available"-like scenenarios.
…is the rule of thumb.
dok-net
force-pushed
the
optimistic_yield_intervals
branch
from
1bf128f
to
342c94e
Compare
The purpose of optimistic_yield is to be used in library functions that get called in tight loops from CONT, in order to avoid unnecessarily frequent yields to SYS, and the performance impact that entails. This PR tries to identify and fix a few places where very low intervals were used for no obvious purpose.