Hi Sylvain, Sylvain Joyeux schrieb: > Hi Pierre. Thanks for the debugging ! > > When you say "immensely", does it become workable with this change ?
i was only waiting for maybe a minute or two, which is mostly masked by packages failing to build on their own. That being said, the cpu time used by amake while in its building package phase went to close to zero, from saturating one of the cpu cores. The number of "stat" syscalls went from 10883398 to 44583. I was suspecting there to actually be a mechanism that prevents amake from making progress at all, but looking at that strace log, i just found that that run was aborted a few 100k stat calls too early to finish. Regards, Pierre > Sylvain > > On Tue, Sep 19, 2017 at 9:07 AM, Pierre Willenbrock <[email protected]> wrote: >> Hello everyone, >> i am not able to reproduce amake being stuck, but i am experiencing >> excessive slowness. I traced that down to Rake::FileTask.needed?(to be >> more specific: Rake::FileTask.out_of_date?) taking a long time to >> recursively check the timestamps of all the prerequisites. >> >> Modifying rake to have Rake::FileTask.out_of_date? like below helps >> immensely(collects the touched tasks first, then checks timestamps): >> >> def out_of_date?(stamp) >> all_prerequisite_tasks.any? { |prereq_task| >> if prereq_task.instance_of?(Rake::FileTask) >> prereq_task.timestamp > stamp || ! >> File.exist?(prereq_task.name) || @application.options.build_all >> else >> prereq_task.timestamp > stamp >> end >> } >> end >> >> The behaviour has changed between rake-12.0.0 and rake-12.1.0. In >> rake-12.0.0, out_of_date? only checked its own timestamp. >> >> Maybe this helps someone. >> >> Regards, >> Pierre >> _______________________________________________ >> Rock-dev mailing list >> [email protected] >> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev > _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
