| 1 |
Daniel Buschke schrieb am 24.05.20 um 00:05: |
| 2 |
> Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier: |
| 3 |
>> Hm correct me if I am wrong, but from looking at the patch Zac |
| 4 |
>> provided I think he meant that the time portage consumes is only one |
| 5 |
>> second while the "rest" is 3.2 seconds. So there is probably a |
| 6 |
>> potential in improving the "rest" somehow. |
| 7 |
> |
| 8 |
> Yes and no. The difference between the python and bash version is |
| 9 |
> roughly 2 seconds. One second for importing portage (which Zac patched |
| 10 |
> away) and another second for the rest of the portage stuff. So using the |
| 11 |
> portage API adds two additional seconds. |
| 12 |
> |
| 13 |
> The python version needs 3.2 seconds on my system. As said the portage |
| 14 |
> API (or better calling the portage API) consumes ~2 seconds. As this is |
| 15 |
> the most time intense part the question is if there is a way to optimize |
| 16 |
> this. |
| 17 |
> |
| 18 |
|
| 19 |
I did run some tests comparing the run time of the bash version, the |
| 20 |
python version, the python version excluding the portage API and the |
| 21 |
python version excluding the portage API AND the data query. I run all |
| 22 |
the commands multiple times for multiple search strings (dropping caches |
| 23 |
in between) and compared the average times excluding min/max values to |
| 24 |
account for network hiccups. |
| 25 |
|
| 26 |
Here the bash version takes around 2.9 seconds while the python version |
| 27 |
takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and |
| 28 |
also excluding the data query it takes 0.3 seconds. So in the python |
| 29 |
version the data query takes 2.5 seconds (probably this is similar for |
| 30 |
the bash version) while all the rest takes 0.7 seconds |
| 31 |
|
| 32 |
My initial tests showed that the bash version is a lot quicker than the |
| 33 |
python version. Somehow I can not reproduce this any more. As mentioned |
| 34 |
previously the data query is the most time consuming part in both the |
| 35 |
bash and the python version. |
| 36 |
|
| 37 |
So I think the python version can compete with the bash version and it |
| 38 |
should be okay to switch to it in upcoming pfl releases. |
| 39 |
|
| 40 |
-- |
| 41 |
Best Regards |
| 42 |
Daniel P :-) |
Archives