3 ms·
I'm not sure that's so much of a problem, I just tried: mkdir uuid; cd uuid uuid -v 4 -n 1000000 |\ while read uuid; do touch $uuid; done An
by e12e 10y ago
I'm not sure that's so much of a problem, I just tried:
mkdir uuid; cd uuid
uuid -v 4 -n 1000000 |\
while read uuid; do
touch $uuid;
done
And ran out of inodes, but:
time ls uuid|wc -l
425621
real 0m1.796s
user 0m1.552s
sys 0m0.240s
Sure, it's not exactly stellar performance for a linear scan of ~400k keys - but it's not terrible (for various values and expectations of terrible).
This is in a hyper-v vm on a Surface 4 pro/i5.
The fact that the "uuid" program can quickly generate uuids make me wonder if maybe one approach would be to generate uuids to (a) fifo(s), and then let db thread/processes read uuids from the other end?
- tyingq 10y agoDepends on the system, and 400k is short of where things tend to go bad on mine. At 800k files I see it taking 7 seconds. Even at 400k files, you see longer wait times if you've aliased ls to ls --color (pretty common), or use something like ls -F. Either runs stat() on every file. Then, somewhere in the 1m+ range, it gets unusable.
- e12e 10y agoOutputting 1m lines to the console is likely to be slow - and isn't really ls' fault?
- tyingq 10y agoFor troubleshooting or statistical reasons. It's serving as the backing data store. So piping through grep, or to wc, etc. Specifically not sending the output to the screen.
- e12e 10y agoSure. As this is a standard Ubuntu install, ls is indeed aliased to "ls --color" - but afaik ls as standard detects pipes, and turns off color (so you don't get a lot of control characters if you do "ls --color | sort > file.txt". Unless you use --color=always if I recall correctly. Just wanted to differentiate between "select * from documents" and "select count(*) from documents" being slow.