~mcoffin


#35 High CPU usage for long lists (~5000 lines) 3 years ago

Comment by ~mcoffin on ~scoopta/wofi

Up, still very much an issue.

Sadly, I can confirm that despite that patch helping, I still do notice this quite frequently as well.

#35 High CPU usage for long lists (~5000 lines) 5 years ago

Comment by ~mcoffin on ~scoopta/wofi

On 2/4/20 3:07 AM, ~ernierasta wrote:

That is reasonable

It's especially reasonable considering the other path to fixing this would be to manually rotate the items into and out of the GTK list as you scroll. (i.e. keep the full list in memory, but only tell GTK about part of it at any given time.

With the way the GTK flowbox and listbox are set up, the inserts are always going to get longer the more items you have.

#35 High CPU usage for long lists (~5000 lines) 5 years ago

Comment by ~mcoffin on ~scoopta/wofi

On 1/29/20 1:49 PM, ~scoopta wrote:

Just making sure you got my reply to your patch, you have gmail and the gmail spam filter likes to drop mail.

That it does. It was in my spam. I'll fix up the patch. Thanks!

I'm probably due for a new email account at some point, but that seems like a pain to update everywhere.

#35 High CPU usage for long lists (~5000 lines) 5 years ago

Comment by ~mcoffin on ~scoopta/wofi

On 1/28/20 6:47 PM, ~scoopta wrote:

0fea34654a97 removes path duplication as a whole.

This has largely resolved the issue for me, though I did have to submit a patch to fix a segfault in that particular changeset

#35 High CPU usage for long lists (~5000 lines) 5 years ago

Comment by ~mcoffin on ~scoopta/wofi

For me, yes. /bin is symlinked to /usr/bin.

It might be worth entirely skipping directories that are symlinked to another entry in $PATH.

On 1/28/20 2:48 PM, ~scoopta wrote:

On your systems is /bin a symlink to /usr/bin? I forgot that run defaults to showing everything in your path including duplicates and I'm wondering if I should change that. It won't increase the performance of wofi as a whole but it will reduce the number of entries generated by run. It's not exactly a fix so much as a mitigation, there's always been an option to disable duplicates it's just off by default. On my system(debian sid) changing that option drops the run load time from 2.5s to under 1s. Again, not a fix but it might be worth while to change that default. I'm still trying to come up with a good way to load stuff as needed. My original idea won't work as it would only be feasible with contains matching and only if you searched for the beginning of the entry, not something in the middle which is admittedly most peoples use but I'm not sure it's a good fix if it's limited to that use.

#35 High CPU usage for long lists (~5000 lines) 5 years ago

Comment by ~mcoffin on ~scoopta/wofi

I am also seeing this issue right now, but even on --show run, since my compgen -c | sort -u | wc -l list is ~5200 entries. I'll take a look around and see what I think could be done as well.