Yes, I thought we at @lge do a lot of builds, but after checking our
statistics we average "only" around 30,000 builds per week in last 5 years.

But on the other hand, our typical image is quite big (between 300MB and
1GB for enduser image and between 700MG and 1.5GB for developer images
depending on the target MACHINE for tar.bz2 IMAGE_FSTYPE), but each build
is producing at least 2 images (enduser and devel), but e.g. TVs are
building 15 different rootfs for each MACHINE, so the number of do_rootfs
tasks is easily over 100,000 per week and I'm seeing average do_rootfs
times around 10-14 minutes for bigger images and 4 minutes for "small"
images.

I should definitely try apk to prevent global warming :).

On Wed, Jul 1, 2020 at 1:15 AM Andre McCurdy <armccu...@gmail.com> wrote:

> On Tue, Jun 30, 2020 at 2:54 PM Martin Jansa <martin.ja...@gmail.com>
> wrote:
> > On Tue, Jun 30, 2020 at 07:01:23PM +0000, Fredrik Gustafsson wrote:
> > > Hi Ross,
> > > those 5 seconds will increase to minutes for my use case and we build
> a lot
> > > hence I hope this will save us a lot of computer power and engineering
> time.
> > > For example I've sent numbers on building a bigger image
> (core-image-sato-sdk-ptest)
> > > to Alex and Alex:
> > > out.apk.1: 1:13.35
> > > out.apk.2: 1:13.51
> > > out.apk.3: 1:13.23
> > > out.apk.4: 1:14.07
> > > out.apk.5: 1:13.00
> > > out.deb.1: 3:49.37
> > > out.deb.2: 3:50.77
> > > out.deb.3: 3:51.39
> > > out.deb.4: 3:53.40
> > > out.deb.5: 3:53.99
> > > out.ipk.1: 2:38.99
> > > out.ipk.2: 2:39.07
> > > out.ipk.3: 2:35.34
> > > out.ipk.4: 2:36.15
> > > out.ipk.5: 2:34.55
> > > out.rpm.1: 1:58.61
> > > out.rpm.2: 1:59.42
> > > out.rpm.3: 1:59.70
> > > out.rpm.4: 1:58.96
> > > out.rpm.5: 1:58.11
> > >
> > > Also consider that if we've a target without python with limited
> space, rpm is out
> > > of the question. So the real comparison would be between ipk and apk.
> Let's
> > > say we can save 80 seconds in each build. Now multiply that with the
> number of
> > > builds, and we do a lot (I guess we might approach 100 000 builds/week
> in the
> > > next year). Then this will save 92.5 days build time each week.
> >
> > This is impressive.
>
> Indeed. 10 builds per minute, 24hrs a day. But not as impressive as
> the scale of the development team able to create enough changes to
> trigger so many builds and the scale of the test infrastructure able
> to consume them!
>
> Assume one developer makes 10 changes a day and each change gets built
> for 10 different targets... 100,000 builds per week implies a team of
> over 140 developers.
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140156): 
https://lists.openembedded.org/g/openembedded-core/message/140156
Mute This Topic: https://lists.openembedded.org/mt/75057633/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to