From: Alexander Dahl <ada@thorsis.com>
To: Christian Melki <christian.melki@t2data.com>
Cc: Michael Olbrich <m.olbrich@pengutronix.de>,
post@lespocky.de, ptxdist@pengutronix.de, CG@eks-engel.de
Subject: Re: [ptxdist] Speed up targetinstall of certain packages
Date: Tue, 8 Nov 2022 13:50:45 +0100 [thread overview]
Message-ID: <Y2pQpYCzl0m7a1Fy@ada.ifak-system.com> (raw)
In-Reply-To: <2aa3b38a-9025-d88e-8364-fea4ada10f3a@t2data.com>
Hello everyone,
Am Tue, Nov 08, 2022 at 11:13:44AM +0100 schrieb Christian Melki:
>
>
> On 11/4/22 8:12 PM, Alexander Dahl wrote:
> > Not sure how that should behave. However if you want to speed up the
> > build: make sure you call ptxdist with -q or --quiet parameter. The
> > output on screen takes suprisingly much time, even with modern
> > terminals, and especially when doing targetinstall of many many files
> > (as usually the case with web frontends. been there, done that.)
> >
> > Greets
> > Alex
> >
>
> I have a slight disagreement here. I don't think the console is slow.
You're right. As already discussed in IRC yesterday: I did some
benchmarks yesterday on the targetinstall stage of a package using
install_tree to install a folder containing 900+ files. Turns out: no
significant difference between running with or without --quiet.
Greets
Alex
> So I did some investigation, mostly since the slowness bugs me too.
> I did a:
> export PS4='+[${EPOCHREALTIME}][${BASH_SOURCE}:${LINENO}]: ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'; set -x;
> as time measurement and trace in the shellscript in question (mostly scripts/lib/ptxd_make_xpkg_pkg.sh).
> This pretty linear progressive cpu consumption, albeit the big chunks were due to calling of external binaries.
>
> Then I did a timezone package clean and targetinstall.
> When targetinstalling a zone there was calls to several binaries.
>
> For one zone I had external calls to (in order):
> echo, mkdir, printf(?), flock, ls, rm, mkdir, flock, mkdir, flock, mkdir, flock, mkdir, flock, mkdir, flock, mkdir, mkdir, mkdir, mkdir, mkdir, install, install, chmod, chmod, chown, echo.
>
> Some of these could be internal builtins, but the consumed time suggested otherwise.
> Either way. Each install took about 26 ms and I could account the majority of that time in forking external programs and waiting for them to return.
>
> So my conclusion is: The whole thing is a bit slow and bash doesn't help.
>
> Regards,
> Christian
>
> > >
> > > Thanks for any feedback.
> > > BR,
> > > Christian
> >
>
next prev parent reply other threads:[~2022-11-08 12:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 15:37 Gieseler, Christian
2022-11-04 19:12 ` Alexander Dahl
2022-11-08 10:13 ` Christian Melki
2022-11-08 12:10 ` Christian Melki
2022-11-11 16:08 ` Michael Olbrich
2022-11-11 17:52 ` Christian Melki
2022-11-08 12:50 ` Alexander Dahl [this message]
2022-11-08 8:25 ` Michael Olbrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2pQpYCzl0m7a1Fy@ada.ifak-system.com \
--to=ada@thorsis.com \
--cc=CG@eks-engel.de \
--cc=christian.melki@t2data.com \
--cc=m.olbrich@pengutronix.de \
--cc=post@lespocky.de \
--cc=ptxdist@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox