On Mon, Nov 26, 2018 at 3:34 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Mon, Nov 26, 2018 at 8:22 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Mon, Nov 26, 2018 at 3:03 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > There's no facts or details, to quote "The reported speed increase for > > > transactions is substantial. This may solve (or greatly reduce) the > > > compose speed problem, TBD." but it doesn't report the context of the > > > "speed increase for transactions" .... like which transactions? > > > There's a lot of I/O heavy processes in the compose, like createrepo, > > > that don't run any rpm tracsactions what so ever. > > > > Paul was referring to image creation here. We should be able to get a > > fairly significant (at least one order of magnitude) speed-up on > > creating any image that runs an RPM installation transaction. I'm not > > sure how much that will save in the *whole* compose process, but as > > it's an identified spot where we know how to optimize it, we should do > > so. > > But ultimately removing rpm transactions is an optimisation to rpm > which, when it lands, the compose plus numerous other compoents that > use that code path will just consume and at that point get the > benefits of, it's not a reason to skip a release nor is it going to be > a revolution that gets the composes down to an hour. I don't believe > that that alone is and order of magnitude change, do you have any > actual hard figured to back the statement up? Paul overstated the general importance of the scriptlet work. As I said above, it will affect the RPM transactions. Will Woods has numbers on the actual performance gains that I'm sure he'll share on this thread at some point. I said above "I'm not sure how much that will save in the *whole* compose process" and I meant that. I'm not advocating that we postpone F31 solely for these changes. At the same time, let's be careful not to slip into a "perfect is the enemy of good" situation where we start critiquing individual solutions as not having enough of an effect. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
