[DiscordArchive] The kernel can handle this stuff way better and already has to do so anyway since multiple processes
[DiscordArchive] The kernel can handle this stuff way better and already has to do so anyway since multiple processes
Original source
Also, tested on Win I/O, it's always a bad idea to call I/O functions to read file per one byte. The best performance is gained when you read file in 4kb blocks
rektbyfaith
06-18-2018, 02:40 PM #11Archived author: Deamon • Posted: 2018-06-18T14:40:01.810000+00:00
Original source
Also, tested on Win I/O, it's always a bad idea to call I/O functions to read file per one byte. The best performance is gained when you read file in 4kb blocks
Original source
Well, 256 KB, to be precise. Last I heard that's what the Windows read size is for cacheable reads
rektbyfaith
06-18-2018, 02:40 PM #12Archived author: Quantam • Posted: 2018-06-18T14:40:45.312000+00:00
Original source
Well, 256 KB, to be precise. Last I heard that's what the Windows read size is for cacheable reads
Original source
But yeah a sector multiple for unbuffered I/O
rektbyfaith
06-18-2018, 02:40 PM #13Archived author: Quantam • Posted: 2018-06-18T14:40:58.458000+00:00
Original source
But yeah a sector multiple for unbuffered I/O
Original source
ah. Well, I haven't experimented with that part for 10 years
rektbyfaith
06-18-2018, 02:41 PM #14Archived author: Deamon • Posted: 2018-06-18T14:41:16.355000+00:00
Original source
ah. Well, I haven't experimented with that part for 10 years
Original source
IIRC 256 KB was also the default read chunk size for asynchronous MPQ read. Though I think they mostly stopped using those by like WC3
rektbyfaith
06-18-2018, 02:44 PM #15Archived author: Quantam • Posted: 2018-06-18T14:44:38.902000+00:00
Original source
IIRC 256 KB was also the default read chunk size for asynchronous MPQ read. Though I think they mostly stopped using those by like WC3
1 Guest(s)
1 Guest(s)