On Tue, Sep 27, 2022 at 03:31:12PM +0200, Renaud Allard wrote: > On 1/16/19 19:09, Otto Moerbeek wrote: > > On Wed, Jan 16, 2019 at 01:25:25PM +0000, Stuart Henderson wrote: > > > > > On 2019/01/04 08:09, Otto Moerbeek wrote: > > > > On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote: > > > > > > > > > > > > > > Very little feedback so far. This diff can only give me valid feedback > > > > > if the coverage of systems and use cases is wide. If I do not get > > > > > more feedback, I have to base my decisions on my own testing, which > > > > > will benefit my systems and use cases, but might harm yours. > > > > > > > > > > So, ladies and gentlemen, start your tests! > > > > > > > > Another reminder. I like to make progress on this. That means I need > > > > tests for various use-cases. > > > > > > I have a map based website I use that is quite good at stressing things > > > (high spin% cpu) and have been timing from opening chromium (I'm using > > > this for the test because it typically performs less well than firefox). > > > Time is real time from starting the browser set to 'start with previously > > > opened windows' and the page open, until when the page reports that it's > > > finished loading (i.e. fetching data from the server and rendering it). > > > > > > It's not a perfect test - depends on network/server conditions etc - and > > > it's a visualisation of conditions in a game so may change slightly from > > > run to run but there shouldn't be huge changes between the times I've > > > run it - but is a bit more repeatable than a subjective "does the browser > > > feel slow". > > > > > > 4x "real" cores, Xeon E3-1225v3, 16GB ram (not going into swap). > > > > > > I've mixed up the test orders so it's not 3x +++, 2x ++, 3x + etc in > > > order, > > > more like +++, -, '', -, ++ etc. > > > > > > +++ 90 98 68 > > > ++ 85 82 > > > + 87 56 71 > > > '' 76 60 69 88 > > > - 77 74 85 > > > -- 48 86 77 67 > > > > > > So while it's not very consistent, the fastest times I've seen are on > > > runs with fewer pools, and the slowest times on runs with more pools, > > > with '' possibly seeming a bit more consistent from run to run. But > > > there's not enough consistency with any of it to be able to make any > > > clear conclusion (and I get the impression it would be hard to > > > tell without some automated test that can be repeated many times > > > and carrying out a statistical analysis on results). > > > > > > > Thanks for testing. To be clear: this is with the diff I posted and not the > > committed code, right? (There is a small change in the committed code > > to change the default to what 1 plus was with the diff). > > > > -Otto > > > > Hello, > > Given that code is in base for about 4 years, shouldn't be the man page > modified to add an explanation for those ++--? Or is there a reason why it's > not documented? > > Best Regards >
No, this is for internal/development use only and might be removed any time. It's undocumented on purpose. -Otto