The first version of prelink in MacOS X took 3-4 hours to run after an install or major update. I assume this prelink is unrelated to the prelink OS X uses, even though IIRC it is opensource? The difference is instead of touting an up to 3200% performance improvement, you are touting an up to 10% performance improvement, which would be kickbutt with 4 megs of ram, and a 33mhz processor. And could be an extremely useful piece of software if used the correct way. But as it stands there is very little benefit unless you can make the buildbots go 10% faster since the one of the challenges this group faces is to get everything compiled once. (which is a major accomplishment and there has been extremely good progress.) There are still 1047 broken dependencies for the armv5tel 14 release according to the daily update and the kernel still needs some cleanup work. If you would like to lend a hand or hardware, it would be welcome. Auto-optimisation from gcc or llvm for simd enhancements could also enhance the chances of welcoming prelinking something like an armv5/armv7/armv7+neon fat binary. But we are a ways off from doing anything remotely resembling that. Im not trying to cut down the effort, it can be -extremely- useful as Apple has demonstrated. However with 1047 broken dependencies, introduction of something else that could introduce errors and cause issues is probably not a wise decision for the overall goals of the projects at this point especially with literally nothing to gain. Big bloated applications have the most to gain which I believe almost all of them at this point still have broken dependencies. I'm not even sure what is gained on the x86 side at this point besides a faster boot and maybe a faster launch for gui apps? Which if you use btrfs as the default filesystem, boot time is about 2x faster then ext4 and if you can actually use video acceleration in gnome, it is orders of magnitudes faster so 10% is a small number. But given I have to use runlevel3 on F16alpha since it broke after an update with no video acceleration, and manually use startx. And grub2 isn't being used for EFI support yet, and systemd is still a bit touchy. Im thinking there are bigger issues to fix. Prelinking maybe the root cause of the corruption of my btrfs filesystem since it took forever to shutdown after an update and I finally just powered off since I had to go and there is no fsck.btrfs to help recover from failed inodes, and gcc wasn't able to install and gnome wasn't acting correctly either. Just something to think about. Quoting Jan Kratochvil <jan.kratochvil@xxxxxxxxxx>: > On Thu, 08 Sep 2011 11:28:52 +0200, Gordan Bobic wrote: >> On Wed, 7 Sep 2011 18:09:34 +0200, Jan Kratochvil > >> <jan.kratochvil@xxxxxxxxxx> wrote: >> > No. Please read /etc/sysconfig/prelink and >> > PRELINK_FULL_TIME_INTERVAL, only >> > once per two weeks. >> >> I meant every time prelink is run, not every time the binary is run. > > There is some misunderstanding here. prelink is run daily and it only > prelinks newly installed/upgraded executables, it does not touch already > prelinked executables. Once per two weeks it re-prelinks everything. > > So if your concerns are about changed executables content (for flash wear > leveling?) that happens at most once per two weeks. I believe this is > negligible change compared to other /var files changing all the time. > > >> You are missing the main point - how much extra CPU and disk I/O is >> that going to take during the backup? > > Less than all the runtime relocations when executing the programs all the > time. > > > Please keep at the facts and not trying to find any possible reason why to > avoid prelink. > > prelink is expected even in the original ELF specification, before any such > program ever existed, as it is the only logical way how to execute ELF files. > > > Thanks, > Jan > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/arm > -- "The information in this email, and attachment(s) thereto, is strictly confidential and may be legally privileged. It is intended solely for the named recipient(s), and access to this e-mail, or any attachment(s) thereto, by anyone else is unauthorized. Violations hereof may result in legal actions. Any attachment(s) to this e-mail have been checked for viruses, but please rely on your own virus-checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications in the matter concerned. If you do not consent to us storing your name and address for above stated purpose, please notify the sender promptly. Also, if you are not the intended recipient please inform the sender by replying to this transmission, and delete the e-mail, its attachment(s), and any copies of it without, disclosing it." _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
