Re: Rough timing of rpm vs opkg rootfs builds

[Mark Hatle <mark.hatle@windriver.com>]

On 11/12/10 9:12 AM, R P Herrold wrote:
> On Fri, 12 Nov 2010, Richard Purdie wrote:
> 
>> I suspect there is an optimisation that can be added for the rpm
>> indexing to make this incremental updating possible.
> 
> Usually naiive ('Rough') timing tests with rpm do not disable 
> un-needed checksum cross checks, key verifications, and such, 
> which are senseless in a closed or protected build environment

RPM resolver db and installation uses minimal options...

Resolver creation:

${RPM} -i --replacepkgs --replacefiles --oldpackage \
 -D "_dbpath $pkgdir/solvedb" --justdb \
 --noaid --nodeps --noorder --noscripts --notriggers --noparentdirs --nolinktos
--stats \
 --ignoresize --nosignature --nodigest \
 -D "_dbi_tags_3 Packages:Name:Basenames:Providename:Nvra" \
 -D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync" \
 $pkgdir/solvedb/manifest


Note the --stats, if you look at the log file, you'll see the timing stats for RPM.


ROOTFS creation:

(generating the resolver solution):
${RPM} -D "_dbpath ${IMAGE_ROOTFS}/install" -D "`cat
${DEPLOY_DIR_RPM}/solvedb.macro`" \
 -D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync" \
 -U --justdb --noscripts --notriggers --noparentdirs --nolinktos \
 ${IMAGE_ROOTFS}/install/install.manifest


Actually doing the install:

${RPM} -D "_dbpath ${IMAGE_ROOTFS}/install" -D "`cat
${DEPLOY_DIR_RPM}/solvedb.macro`" \
 -D "__dbi_cdb create mp_mmapsize=128Mb mp_size=1Mb nofsync private" \
 -U --justdb --noscripts --notriggers --noparentdirs --nolinktos \
 $pkg_name >> "${WORKDIR}/temp/log.do_rootfs_attemptonly.${PID}" || true

So we are doing package validation and related work during FS generation, but
NOT suring the resolver setup.  (Note, according to the above we are validating
packages for the resolver solution... which likely is a mistake and causing
extra time.)

I'm hesitant to add the --nosignature --nodigest to the actual install step, but
adding it to the resolver step might be beneficial.

> Publishing the testing harnesses would permit evaluation of 
> such -- absent a second person checking the methodology, it is 
> probably premature to start kinkering.  Publishing final 
> numbers without a reproduceable methodology is just not good 
> science
> 
> -- Russ herrold
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky