Taking forever to open a folder in chrome to upload a pic

[Hastur]

I am running
1 qbittorrent
2 ffmpeg to convert small video downloads into smaller mp4

As I use chrome, and open for example a pic upload it takes like 6 seconds for the folder to display its contents.
Is there any way to speed this up?

 

[T-Daemon]

2 ffmpeg to convert small video downloads into smaller mp4

This might consume all the CPUs, slowing down all other processes. What does top(1) show?

If ffmpeg is using all the CPU's, you could try cpuset(1) to limit the CPUs used (see EXAMPLES how to configure).

 

[drhowarddrfine]

the folder

The directory. This ain't Windows.

 

[cracauer@]

During those 6 seconds you should have enough time to observe in top(1) whether the Chrome process takes CPU time. If not you are disk bound.

I am disappointed that you ask a performance question but say nothing about your hardware. For starters, what kind of disk is in there?

Which Chrome do you use? Chromium or Linux-chrome?

 

[Hastur]

The directory. This ain't Windows.

I choose shorter easier word This is the net.

 

[Hastur]

During those 6 seconds you should have enough time to observe in top(1) whether the Chrome process takes CPU time. If not you are disk bound.

I am disappointed that you ask a performance question but say nothing about your hardware. For starters, what kind of disk is in there?

Which Chrome do you use? Chromium or Linux-chrome?

Chromium (Didn't know about Linux-chrome until now)
As far as top, there is a lot of cpu being used and ZFS arc is active and various RAM sections BSD shows.....
MY question is my is it so slow? How can I speed it up?

 

[drhowarddrfine]

I choose shorter easier word

But incorrect word. A folder is not a directory and vice-versa. A folder is a graphical representation. A directory is not. You can mount a directory. You can't mount a folder.

A (very) few want to argue with me about this but I won't argue back. There is nothing to argue about.

 

[T-Aoki]

MY question is my is it so slow? How can I speed it up?

No one can answer. This usually strongly depends on workload per hardware performance and you've not disclosed the mandatory info to determine the cause as cracauer@ already mentioned.

The only thing thad does NOT depends on "local" hardwares and I can recall is using toooooooooooooooooooooo outdated versions of FreeBSD itself and ports/pkgs. File dialog of Gtk3 was unusabully slow when it was first introduced into ports tree, and when not-so-fast remote filesystems are mounted. This was fixed by updates to devel/glib20, but it was years ago that is too hard to find a proper link about it for you.
This cannot happen if you're using supported version of FreeBSD and up-to-date ports / pkgs, as the fix is already there.

 

[Hastur]

I wish the operating system was CIP or command input priority. Whatever input is currently active, a xterm or a tab on firefox, should be few milliseconds latency at most. The rest of the jobs running; ffmpeg, qbittorrent, should all WAIT until the command is processed, or what the command asks for is processed, before resuming thier tasks. I don't know how the scheduler gets its task queue...... but to be that would be ideal. I have various folders that I can remvoe most of old files from , and not mix html files with jpg and pics.... but constantly draining them is a bore. I heard a while ago that openVMS had indexed folders. Maybe that is the future.

 

[Alain De Vos]

You could make .cache/chromium a tmpfs filesystem ?
Is your hard disk nvme , ssd or spinning ?
PS :
On my nvme drive i have :
- 32GB swap
- 32GB zpool special device
- 32GB zpool log device
- 64GB zpool cache device

 

[Hastur]

During those 6 seconds you should have enough time to observe in top(1) whether the Chrome process takes CPU time. If not you are disk bound.

I am disappointed that you ask a performance question but say nothing about your hardware. For starters, what kind of disk is in there?

Which Chrome do you use? Chromium or Linux-chrome?

I don't see other chromes in pkg search
freebsd 15p7 icewm chrome or fox when I goto upload a pic the file picker blank white as zfs crunches away for liek 13 seconds finally fills screen....HOW do I speed this up?

 

[Hastur]

I don't see other chromes in pkg search
freebsd 15p7 icewm chrome or fox when I goto upload a pic the file picker blank white as zfs crunches away for liek 13 seconds finally fills screen....HOW do I speed this up?

IS the only way to make this fast to move aside the directory and then only put few pics in the directory?

 

[drhowarddrfine]

freebsd 15p7 icewm

I open directories all day long with tons of videos and images. I don't run icewm. I'm wondering if icewm or its configuration is the problem. Perhaps you can install another wm and try it there.

 

[MG]

Chrome runs as user that has no write permission there? I often try chmod a+rwx temporarily to make sure we're not having a permission denied for some reason.

 

[Hastur]

Chrome runs as user that has no write permission there? I often try chmod a+rwx temporarily to make sure we're not having a permission denied for some reason.

My user can write to the directory...It's READING when I want to upload a pic that gies me white window of the browser to pick the file .... The directory can have 100s of files in it... When I remove them and have only say 4 files its fast....

 

[MG]

My user can write to the directory...It's READING when I want to upload a pic that gies me white window of the browser to pick the file .... The directory can have 100s of files in it... When I remove them and have only say 4 files its fast....

Try Google: chrome select file dialog lag.
I don't use Chrome but those 6 seconds feel like a network timeout of something or a file or directory being somehow in use by something outside chrome..

 

[T-Aoki]

I've experienced similar (but far more worse) experience years ago (took minutes[!] until file dialog opens if the most recently opened directory or any of "recently used" item is in remote SMB/CIFS share) on Gtk3 apps including www/firefox and www/chromium. Even light-weighted editors/leafpad was affected.

But this was fixed if the patch at PR 214338 is applied and FAM_ALTBACKEND option is enabled. And this was committed at revision 565264 (era when ports tree is managed using subversion!) at Feb.14, 2021.

This was backed out at commit af48093c3fba7a167e36cd9092805e326a7c9253 done at Dec.02, 2025 as of the implementation of inotify in-base at stable/15 at commit f1f230439fa48581f40a57f095627f667a9713c3 done at Jul.04, 2025 (15.0 already have it as it's before the announcement at Dec.2, 2025) and updates for devel/libinotify.

Note that FAM_ALTBACKEND was NOT the default and needed to enable and building devel/glib20 locally.
So if you're using pkg, the deletion shouldn't harmed for you, though.