From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6DBC613800E for ; Fri, 31 Jan 2014 22:13:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 52D4BE0B31; Fri, 31 Jan 2014 22:13:06 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 21B40E0A8B for ; Fri, 31 Jan 2014 22:13:04 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id y10so9895864wgg.20 for ; Fri, 31 Jan 2014 14:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QM8b784g3VbM5dFOiBUNIgKft6v0IqW4bVupxZTSlMY=; b=VDJRGDt+fzLEyj1WYg05nU2pdPdpuP66L4M2z7HgmHSxpggGwAiy4kGfuSPo7c/xjo RdP6RceqM+M/AAz6QXf5zZR2edFv/4kmyU5bEegAUgz+/T/n6pLbs7blK74pq+OdEq0r +ebhewZvSMT0UsveeRZmN9vN35gv/vhkdWOMNz7zZemhErjiHGaYBtzCkXho10nbNCL5 rojo4BDd7aIqfOAfwM9/DNpImAHYiW+NeJhhsZNf5ryMOr2j0iTxxfkcSAfNLgv7fY/9 ioj6qR6EJKcrX1DMk8w2YMsDiUl59COwUjkkb6aIPlEmmwiSWn138zChBFrUuLvX7jpx 3mnw== X-Received: by 10.180.79.7 with SMTP id f7mr486409wix.20.1391206383412; Fri, 31 Jan 2014 14:13:03 -0800 (PST) Received: from [172.20.0.40] (196-210-244-57.dynamic.isadsl.co.za. [196.210.244.57]) by mx.google.com with ESMTPSA id a9sm1133113wiy.10.2014.01.31.14.13.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 14:13:02 -0800 (PST) Message-ID: <52EC1FEA.5090308@gmail.com> Date: Sat, 01 Feb 2014 00:12:58 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Portage performance dropped considerably References: <52E5543B.4070808@gmail.com> <20140131230305.1b4ee153af223fd43f541fac@gmail.com> <201401311913.45133.michaelkintzios@gmail.com> <20140201011821.5d386f29024e40bd6bcc4ed5@gmail.com> In-Reply-To: <20140201011821.5d386f29024e40bd6bcc4ed5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 47f392c9-a241-4efe-a0f5-b58c34dce369 X-Archives-Hash: a7123fb68b095f3b8fc515aeeba908b6 On 31/01/2014 23:18, Andrew Savchenko wrote: > IMO the only way to improve this issue (without throwing good working > hardware in the window) is to rewrite dependency resolution code in > some highly optimized pure C library (probably with some asm code) I very much doubt that will help. There's nothing unusual about portage's dep resolution - it's just a tree search. This is a well-understood problem and we've known how to DoItRite for 30 years or more. Python is already optimized to do this just fine, and it's bytecode, NOT classic interpreted. Rewriting it in C probably won't do much as C isn't a magic bullet. > and to use this library via some python binding from portage. But I > suppose algorithm itself should be reviewed first. ^this is where the speedups will lie 4 minutes on this here i7 monster and 40 on your Atom is ridiculous considering the problem that is being solved. Portage is probably searching and re-searching dead paths in the tree or something equally silly. The algorithm should be analysed and dead paths optimized away. Not a language problem. -- Alan McKinnon alan.mckinnon@gmail.com