Профилирование доступа к диску
Я считаю, что если нет хорошего способа использовать Optional, то нет никаких оснований пытаться использовать его в любом случае.
Я считаю, что это чище и проще, чем ваш вариант 2:
String a = getA().orElse(null);
String b = getB().orElse(null);
if(a != null && b != null) {
return f(a, b);
}
3 ответа
You can use the Windows Performance Toolkit for this. You can enable trace providers for disk I/O events and see the I/O time and disk service time for each. It does have a bit of a learning curve though. This will also let you determine which file I/O's actually result in real-access to the disk and aren't handled by the cache manager.
Most important parameters are disk service time and queue length. Disk service time is how long the disk actually took to service the request. Queue length indicates if your disk request is backed up behind other requests.
For many threads w/ reads & writes - Many disks have poor performance in the face of reads with background writes. If you have various threads doing lots of disk I/O to random locations on the disk, you may wind up starving certain requests.
Чтобы помочь вам с (2):
- Попытайтесь выполнить пакетную запись ваших записей на диск, чтобы избежать множества небольших вызовов записи. Когда вы закончите очищать свой буфер, вызовите commit. commit (он же fsync) - это дорогостоящая операция, поэтому она становится еще более важной, когда много мелких записей.
- На дескрипторах файлов Windows вы можете поэкспериментировать с FILE FLAG WRITE THROUGH для увеличения скорости записи. Предположительно, не нужно вызывать commit с дескрипторами, использующими этот флаг.
- Если данные, которые вы записываете на диск, также будут доступны при чтении, сначала рассмотрите возможность записи в структуру в памяти, чтобы другой поток считывал из структуры для записи на диск. Это поможет избежать вызовов для чтения данных с диска, который вы только что записали.
Надеюсь, это поможет ....
What I would do is, if you can't pause all threads at the same time and examine their state, focus on one of them and pause that, while it's being "damn slow". This is a little known but effective technique.
Since it is being extremely slow compared to what it could be, whatever it is waiting for it is waiting for probably 99% of the time, so when you pause it you will see it. That's true whether it's one big wait, or a zillion little ones. Look at the whole call stack. The culprit may be somewhere in the middle of the stack.
If you're not sure, pause it two or three times. The culprit will be on all stack samples.