Thanks for all replies. I did not track forks with strace since "I do
not have such code" although stack has threaded and rtsopts set. But
now `strace -f` clearly shows that there are qutie a lot of forking
for my code. Removing those options got me a 3% CPU usage reducing.
And as Neil said, ioctl or other syscalls in the whole reading
process, Haskell is more optimized than Rust.
I am trying posix-paths now.
@Viktor,
Sorry, that was a part missing in sample code. isMyPid should be
called before reading the stat file.
@Brandon, @Joachim, @KC,
At least for me, how data is stored on disk is not related. /proc is a
virtual filesystem which just a kernel data structures exposed via IO
operations.
On Sun, May 12, 2019 at 2:27 PM Joachim Durchholz
Am 12.05.19 um 00:23 schrieb KC:
Are directories stored in consecutive disk blocks?
That's something that you have to rely on the file system to organize for you. Brandon's answer is the traditional one for Unix filesystems, up to and including ext3fs. Modern filesystems try to do better (and often do), since scanning large directories has turned out to be so important. If you do performance testing, both bad and good filesystem performance may be accidental; if you want to know not just the typical behaviour but also the pathological cases, you'll either have to wait for user reports to come in or talk to real filesystem experts (and even their answers will mostly be on an "it depends" basis). Note that fragmentation is irrelevant for SSDs.
The OP is at the "what system calls are being done" stage; optimization questions about fragmentation aren't going to be relevant to him I think.
TL;DR: Don't worry about fragmentation, unless you are willing to spend a really high amount of time on detail optimization.
Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.