On 5/24/20 9:40 AM, Daniel Buschke wrote:
> Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier:
>> Here the bash version takes around 2.9 seconds while the python version
>> takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and
>> also excluding the data query it takes 0.3 seconds. So
Sending from the proper address so this mail also reaches the list!
Daniel Buschke schrieb am 24.05.20 um 18:40:
> Oh dear! I readded the database index for file names. Now the data query
> takes ~0.3 seconds *insert self slapping image here*
Good to hear! Now it's way quicker!
> Anyway, for
Am 24.05.2020 um 14:10 schrieb Daniel Pielmeier:
Here the bash version takes around 2.9 seconds while the python version
takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and
also excluding the data query it takes 0.3 seconds. So in the python
version the data query takes 2.5
Daniel Buschke schrieb am 24.05.20 um 00:05:
> Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier:
>> Hm correct me if I am wrong, but from looking at the patch Zac
>> provided I think he meant that the time portage consumes is only one
>> second while the "rest" is 3.2 seconds. So there is probably
Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier:
Hm correct me if I am wrong, but from looking at the patch Zac provided
I think he meant that the time portage consumes is only one second while
the "rest" is 3.2 seconds. So there is probably a potential in improving
the "rest" somehow.
Yes
Am May 23, 2020 9:17:46 PM UTC schrieb Daniel Buschke
:
>Am 23.05.2020 um 22:55 schrieb Zac Medico:
>> Since the portage API only added about 1 second to the python script
>> time, I guess it's on par with your bash implementation. ;-P
>
>Yeah, if you substract the second for loading and the
Am 23.05.2020 um 22:55 schrieb Zac Medico:
Since the portage API only added about 1 second to the python script
time, I guess it's on par with your bash implementation. ;-P
Yeah, if you substract the second for loading and the second for doing
queries, then yes, it's pretty par with the bash
On 5/23/20 1:41 PM, magic-gen...@damage.devloop.de wrote:
> Am 23.05.2020 um 22:20 schrieb Zac Medico:
>> On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote:
>>> I rewrote e-file in python by using the portage API [1]. But loading the
>>> API slows down the whole script. Is there any way to
Am 23.05.2020 um 22:20 schrieb Zac Medico:
On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote:
I rewrote e-file in python by using the portage API [1]. But loading the
API slows down the whole script. Is there any way to speed up my
implementation? Have I done something fundamentally
Hi,
Am 23.05.2020 um 22:08 schrieb Michał Górny:
On Sat, 2020-05-23 at 22:02 +0200, magic-gen...@damage.devloop.de wrote:
I rewrote e-file in python by using the portage API [1]. But loading the
API slows down the whole script. Is there any way to speed up my
implementation? Have I done
On 5/23/20 1:02 PM, magic-gen...@damage.devloop.de wrote:
> Hi,
> the current e-file tool of app-portage/pfl is written in bash. e-file is
> a CLI tool which searches portagefilelist.de for a given file and list
> additional informations based on the local portage. Latter is done by
> grep'ing
On Sat, 2020-05-23 at 22:02 +0200, magic-gen...@damage.devloop.de wrote:
> Hi,
> the current e-file tool of app-portage/pfl is written in bash. e-file is
> a CLI tool which searches portagefilelist.de for a given file and list
> additional informations based on the local portage. Latter is done
Hi,
the current e-file tool of app-portage/pfl is written in bash. e-file is
a CLI tool which searches portagefilelist.de for a given file and list
additional informations based on the local portage. Latter is done by
grep'ing through the ebuild files which is fast but IMHO not very smart.
I
13 matches
Mail list logo
