Gentoo Archives: gentoo-dev

From: "William L. Thomson Jr." <wlt-ml@××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds
Date: Tue, 11 Jul 2017 01:42:23
Message-Id: assp.03652bdcd2.20170710214217.1c6a1291@o-sinc.com
In Reply to: Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds by Ciaran McCreesh
1 On Tue, 11 Jul 2017 02:23:56 +0100
2 Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
3
4 > On Mon, 10 Jul 2017 18:14:23 -0700
5 > Raymond Jennings <shentino@×××××.com> wrote:
6 > > If I may ask, does anyone have any profiling information one way or
7 > > the other to shed light on the situation?
8
9 There are profilers for python. Python devs can comment on such. I am
10 not sure about other things like looking for leaks etc. I was not able
11 to run python stuff through valgrind. At least I could not run
12 java-config through valgrind like I do with jem.
13
14 IMHO python all around is just not as robust and should not be used for
15 such purposes. There maybe ways to make it faster. For something with
16 the complexity, it should really be done in something more robust. Just
17 requires talent to make it such.
18
19 > Paludis does complete dependency and unused package tracking for
20 > everything by default. Any performance difficulties are
21 > implementation-related, not a fundamental problem.
22
23 I agree its a portage issue. Not saying anyone's code sucks or
24 discounting their efforts. Things do not have to be slow.
25
26 I mentioned this directly to some portage people in person a few years
27 ago during a meeting in Southern California... Around the time I put
28 jem on Github.
29
30 It is really hard to start over if/when that happens. Thus doing it
31 piece meal maybe easier. Though may still end up with spaghetti in the
32 end. Hopefully it runs fast and taste good :)
33
34 --
35 William L. Thomson Jr.