Also, specifically for 29938: I tested it and it appears to break the TEST_DEBUG usage.
So in my view it strengthens the case for having the non-performance-critical code that is the obvious to read and modify. --a On 11/18/20, Andrew Yourtchenko via lists.fd.io <ayourtch=gmail....@lists.fd.io> wrote: > > >> On 18 Nov 2020, at 04:35, Paul Vinciguerra <pvi...@vinciconsulting.com> >> wrote: >> >> >> reposting to the list. >> >> 2400 for each 'make test' run. > > Yeah so then it probably would make less than a second of run time - in this > case I would squarely optimize for a better readability by the unsuspecting > person later on. > > Arguably it’s a trickier criterion though, since probably depends on what > one is used to. > > —a > >> >>> On Tue, Nov 17, 2020 at 10:27 PM Paul Vinciguerra >>> <pvi...@vinciconsulting.com> wrote: >>> 2400 for each 'make test' run. >>> >>>> On Tue, Nov 17, 2020 at 5:48 PM Andrew 👽 Yourtchenko >>>> <ayour...@gmail.com> wrote: >>>> Paul, is it 2400 comparisons per single test or 2400 comparisons in >>>> total ? >>>> >>>> If the latter, I would rather optimize for readability, since it’s >>>> probably less than a second of run time. >>>> >>>> Specifically about the example with debugging of internals - replacing >>>> the hooks with subclassing hinders the intent imho - for that particular >>>> case. >>>> >>>> --a >>>> >>>>>> On 17 Nov 2020, at 19:50, Paul Vinciguerra >>>>>> <pvi...@vinciconsulting.com> wrote: >>>>>> >>>>> >>>>> Ok. This is a backwards request. I'm asking for help trying to >>>>> explain properly why I've -2'd a change. The code is both useful to >>>>> the community and cleanly written. I think the plumbing needs some >>>>> help. When we find someone who is willing and able to contribute, I'd >>>>> like to not frustrate them away. >>>>> >>>>> At a high level, when we run tests, the makefile sets up a specific >>>>> environment that is passed to run_tests.py (which is a >>>>> re-implementation of the python stdlib unittest. test runner). The >>>>> test runner does discovery, that is that it finds all the tests that >>>>> match a customized string, and builds a list of tests which are either >>>>> run serially or forked in parallel. >>>>> >>>>> What people have done is put conditional logic in the test case and >>>>> change the behavior after the test has started. I consider this >>>>> analogous to you unrolling a loop and me coming by and testing if 1==2 >>>>> for each element of your unrolled loop. >>>>> >>>>> The test should instead be done once in the runner, instead of 2400 or >>>>> so times for every submission into the gate. >>>>> >>>>> To explain this, I cherry-picked some of my code and submitted it as an >>>>> example. My example is here: https://gerrit.fd.io/r/c/vpp/+/29938. >>>>> It' not something I planned to contribute, but I changed it enough to >>>>> get it to pass the date. >>>>> >>>>> The commit I am blocking is here: https://gerrit.fd.io/r/c/vpp/+/29921 >>>>> . >>>>> >>>>> How do I, with limited cycles, convey what needs to be done without >>>>> writing sample code or going in and patching over someone's work. >>>>> The code is well written and I'd rather +2 it and try to coax some more >>>>> contributions. ;) >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18077): https://lists.fd.io/g/vpp-dev/message/18077 Mute This Topic: https://lists.fd.io/mt/78323128/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
