Less i/o for the ProBalance restraint the process and log it every second?
----
Just wanna know, did you use any Flag like FILE_FLAG_WRITE_THROUGH? :)
I use FILE_ATTRIBUTE_TEMPORARY for the log file. This causes maximum buffering, as the data in the log isn't that important.
FILE_FLAG_WRITE_THROUGH would be detrimental to performance, forcing all writes to be committed to disk ASAP. It's used for more sensitive data that you don't want to lose in the event of a loss of power.
Quote from: Support on April 18, 2013, 04:27:46 AM
I have been using FILE_ATTRIBUTE_TEMPORARY, though am not sure it makes much difference.
FILE_FLAG_WRITE_THROUGH would be detrimental to performance, forcing all writes to be committed to disk immediately.
But make sure that it has been write to hard disk?
I wonder did FILE_FLAG_WRITE_THROUGH can skip over some software buffer like collect first, then write the data together to disk every 10 second, like FancyCache?
----
FILE_ATTRIBUTE_TEMPORARY, so did it always keep the file in the Ram, even the Trim virtual memory function is used for PL process?
Then it should be make a difference for computer that always used fully the Ram. ;)
All file writes are normally cached for some period of time.
Writes to temporary files are cached longer, as their contents aren't deemed that important if they were to be lost to a sudden loss power power.
Writes to write-through files are written on through to the disk immediately. The disk write cache may cache them a bit, but, generally, the intent is to get their contents to disk as fast as possible, in case there is a loss of power.
An ideal balance of speed vs data safety is the default behavior if neither file attribute is specified.
UPDATE:
I get your question now (https://bitsum.com/forum/Smileys/default/wink.gif).
FILE_ATTRIBUTE_TEMPORARY does not force the file to remain entirely in RAM, though it may encourage it to be kept in RAM, depending if it is referenced a lot. It's more about write caching. Also, as of v6.0.3.9, the maximum size any log file will be is 512Kb. So, it hardly matters.
But, it is important for HDD user, as you can see with Windows Task Manager, it is showing like 4.x MB/s with 2xxxms access time when heavy I/O. ;D
512/4096Kb=12.5%=250ms
WoW! :o
But as the size is not that "big", and windows don't throw all the cache when the Ram is nearly full.
So yes, hardly matters. ;)
----OT line
I found you are forcing using HTTPS for all the forum link, but in Nightly.
They block anything that don't go through http, and some object on the forum(might be other thing that don't come from bistum server) is using http.
Just let you know before this feature landed on Release. ;)
The file isn't kept entirely in memory even with that attribute. Also, Process Lasso doesn't read the entire file. Since it is a flat file, it can skip to the last 100 entries say, whatever the limit is on the listview. It closes and re-opens the file each time it references it, so I'm pretty certain *if* there is *anything important* needing that memory, Windows will not make the temporary file a priority.
Quote from: BenYeeHua on April 18, 2013, 06:14:42 AM
I found you are forcing using HTTPS for all the forum link, but in Nightly.
They block anything that don't go through http, and some object on the forum(might be other thing that don't come from bistum server) is using http.
Just let you know before this feature landed on Release. ;)
Yes, I've been playing with the forum settings. I'll change it back.
default sounds much better IMO, you don't want to add any I/O activity if you can help it .
Quote from: Support on April 18, 2013, 06:21:15 AM
The file isn't kept entirely in memory even with that attribute. Also, Process Lasso doesn't read the entire file. Since it is a flat file, it can skip to the last 100 entries say, whatever the limit is on the listview. It closes and re-opens the file each time it references it, so I'm pretty certain *if* there is *anything important* needing that memory, Windows will not make the temporary file a priority.
Thank for telling that, time to learn about flat file.
Quote from: edkiefer on April 18, 2013, 08:17:56 AM
default sounds much better IMO, you don't want to add any I/O activity if you can help it .
Ya, except PL log is very important for some people which having a issues for BSOD and power supply. ;D
I would think event viewer and BSOD code viewer be more important .
Quote from: edkiefer on April 18, 2013, 08:43:24 AM
I would think event viewer and BSOD code viewer be more important .
And PSU. ;)
But most people don't know how to debug/give the dump/minidump to find out/let other people find out why it BSOD. :P
::) Well, back on some topic. In the end, I believe I've implemented things right. If I find cause to change, I'll do so..