Dnia June 28, 2020 3:42:33 AM UTC, Zac Medico napisał(a):
>On 6/27/20 8:12 PM, Michał Górny wrote:
>> Dnia June 28, 2020 3:00:00 AM UTC, Zac Medico
>napisał(a):
>>> On 6/26/20 11:34 PM, Chun-Yu Shei wrote:
Hi,
I was recently interested in whether portage could be speed up,
>since
On 6/27/20 8:12 PM, Michał Górny wrote:
> Dnia June 28, 2020 3:00:00 AM UTC, Zac Medico napisał(a):
>> On 6/26/20 11:34 PM, Chun-Yu Shei wrote:
>>> Hi,
>>>
>>> I was recently interested in whether portage could be speed up, since
>>> dependency resolution can sometimes take a while on slower
Dnia June 28, 2020 3:00:00 AM UTC, Zac Medico napisał(a):
>On 6/26/20 11:34 PM, Chun-Yu Shei wrote:
>> Hi,
>>
>> I was recently interested in whether portage could be speed up, since
>> dependency resolution can sometimes take a while on slower machines.
>> After generating some flame graphs
On 6/26/20 11:34 PM, Chun-Yu Shei wrote:
> Hi,
>
> I was recently interested in whether portage could be speed up, since
> dependency resolution can sometimes take a while on slower machines.
> After generating some flame graphs with cProfile and vmprof, I found 3
> functions which seem to be
On Sat, 2020-06-27 at 14:00 +, Joakim Tjernlund wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> I am trying to add -fdebug-prefix-map to my CFLAGS but
I am trying to add -fdebug-prefix-map to my CFLAGS but cannot get past
"$(readlink -f ..)"
Portage will not expand $(anything)
Any way to make portage expand "$(readlink -f ..)" ?
Jocke
Dnia June 27, 2020 6:34:13 AM UTC, Chun-Yu Shei napisał(a):
>According to cProfile, catpkgsplit is called up to 1-5.5 million times
>during "emerge -uDvpU --with-bdeps=y @world". Adding a dict to cache
>its
>results reduces the time for this command from 43.53 -> 41.53 seconds
>--
>a 4.8%
This function is called extremely frequently with similar arguments, so
this optimization reduces "emerge -uDvpU --with-bdeps=y @world" runtime from
43.5 -> 34.5s -- a 25.8% speedup.
---
lib/portage/dep/__init__.py | 26 ++
1 file changed, 26 insertions(+)
diff --git
Hi,
I was recently interested in whether portage could be speed up, since
dependency resolution can sometimes take a while on slower machines.
After generating some flame graphs with cProfile and vmprof, I found 3
functions which seem to be called extremely frequently with the same
arguments:
According to cProfile, catpkgsplit is called up to 1-5.5 million times
during "emerge -uDvpU --with-bdeps=y @world". Adding a dict to cache its
results reduces the time for this command from 43.53 -> 41.53 seconds --
a 4.8% speedup.
---
lib/portage/versions.py | 7 +++
1 file changed, 7
This function is called frequently with similar arguments, so cache as
much of the partial results as possible. It seems that "match_from_list"
must return a list containing actual entries from the "candidate_list" argument,
so we store frozensets in "_match_from_list_cache" and test items from
On Sat, 27 Jun 2020 at 19:35, Fabian Groffen wrote:
>
> Hi Chun-Yu,
> > arguments: catpkgsplit, use_reduce, and match_from_list. In the first
> > two cases, it was simple to cache the results in dicts, while
> > match_from_list was a bit trickier, since it seems to be a requirement
> > that it
Hi Fabian,
Just eyeballing htop's RES column while emerge is running, the max
value I see during "emerge -uDvpU --with-bdeps=y @world" increases
from 272 MB to 380 MB, so it looks to be around 110 MB of extra memory
usage on my system (with 1,094 total packages installed).
Chun-Yu
On Sat, Jun
Hi Chun-Yu,
On 26-06-2020 23:34:12 -0700, Chun-Yu Shei wrote:
> Hi,
>
> I was recently interested in whether portage could be speed up, since
> dependency resolution can sometimes take a while on slower machines.
> After generating some flame graphs with cProfile and vmprof, I found 3
>
14 matches
Mail list logo