1 |
On Thu, Jul 9, 2020 at 12:03 AM Chun-Yu Shei <cshei@××××××.com> wrote: |
2 |
|
3 |
> Awesome! Here's a patch that adds @lru_cache to use_reduce, vercmp, and |
4 |
> catpkgsplit. use_reduce was split into 2 functions, with the outer one |
5 |
> converting lists/sets to tuples so they can be hashed and creating a |
6 |
> copy of the returned list (since the caller seems to modify it |
7 |
> sometimes). I tried to select cache sizes that minimized memory use |
8 |
> increase, |
9 |
> while still providing about the same speedup compared to a cache with |
10 |
> unbounded size. "emerge -uDvpU --with-bdeps=y @world" runtime decreases |
11 |
> from 44.32s -> 29.94s -- a 48% speedup, while the maximum value of the |
12 |
> RES column in htop increases from 280 MB -> 290 MB. |
13 |
> |
14 |
> "emerge -ep @world" time slightly decreases from 18.77s -> 17.93, while |
15 |
> max observed RES value actually decreases from 228 MB -> 214 MB (similar |
16 |
> values observed across a few before/after runs). |
17 |
> |
18 |
> Here are the cache hit stats, max observed RES memory, and runtime in |
19 |
> seconds for various sizes in the update case. Caching for each |
20 |
> function was tested independently (only 1 function with caching enabled |
21 |
> at a time): |
22 |
> |
23 |
> catpkgsplit: |
24 |
> CacheInfo(hits=1222233, misses=21419, maxsize=None, currsize=21419) |
25 |
> 270 MB |
26 |
> 39.217 |
27 |
> |
28 |
> CacheInfo(hits=1218900, misses=24905, maxsize=10000, currsize=10000) |
29 |
> 271 MB |
30 |
> 39.112 |
31 |
> |
32 |
> CacheInfo(hits=1212675, misses=31022, maxsize=5000, currsize=5000) |
33 |
> 271 MB |
34 |
> 39.217 |
35 |
> |
36 |
> CacheInfo(hits=1207879, misses=35878, maxsize=2500, currsize=2500) |
37 |
> 269 MB |
38 |
> 39.438 |
39 |
> |
40 |
> CacheInfo(hits=1199402, misses=44250, maxsize=1000, currsize=1000) |
41 |
> 271 MB |
42 |
> 39.348 |
43 |
> |
44 |
> CacheInfo(hits=1149150, misses=94610, maxsize=100, currsize=100) |
45 |
> 271 MB |
46 |
> 39.487 |
47 |
> |
48 |
> |
49 |
> use_reduce: |
50 |
> CacheInfo(hits=45326, misses=18660, maxsize=None, currsize=18561) |
51 |
> 407 MB |
52 |
> 35.77 |
53 |
> |
54 |
> CacheInfo(hits=45186, misses=18800, maxsize=10000, currsize=10000) |
55 |
> 353 MB |
56 |
> 35.52 |
57 |
> |
58 |
> CacheInfo(hits=44977, misses=19009, maxsize=5000, currsize=5000) |
59 |
> 335 MB |
60 |
> 35.31 |
61 |
> |
62 |
> CacheInfo(hits=44691, misses=19295, maxsize=2500, currsize=2500) |
63 |
> 318 MB |
64 |
> 35.85 |
65 |
> |
66 |
> CacheInfo(hits=44178, misses=19808, maxsize=1000, currsize=1000) |
67 |
> 301 MB |
68 |
> 36.39 |
69 |
> |
70 |
> CacheInfo(hits=41211, misses=22775, maxsize=100, currsize=100) |
71 |
> 299 MB |
72 |
> 37.175 |
73 |
> |
74 |
> |
75 |
> I didn't bother collecting detailed stats for vercmp, since the |
76 |
> inputs/outputs are quite small and don't cause much memory increase. |
77 |
> Please let me know if there are any other suggestions/improvements (and |
78 |
> thanks Sid for the lru_cache suggestion!). |
79 |
> |
80 |
|
81 |
I don't see a patch attached; can you link to it? |
82 |
|
83 |
-A |
84 |
|
85 |
|
86 |
> |
87 |
> Thanks, |
88 |
> Chun-Yu |
89 |
> |
90 |
> |
91 |
> |
92 |
> |