On Wednesday 11 June 2008, Chuck Swiger wrote:
If your data files are small enough to fit into 2GB of address space,
try using mmap() and then treat the file(s) as an array of records or
memoblocks or whatever, and let the VM system deal with paging in the
parts of the file you need.
On Thursday 05 June 2008, Kirk Strauser wrote:
I was testing the same software on my desktop PC when I noticed that it
ran *much* faster, and found that it was spending only about 1% as much
time in the kernel on Linux as it was on FreeBSD.
I'm almost ready to give up on this. I've gone as
On Wednesday 11 June 2008, Kirk Strauser wrote:
On Linux:
$ time ./cdbf /tmp/invoice.dbf /dev/null
./cdbf /tmp/invoice.dbf /dev/null 42.65s user 20.09s system 71% cpu
1:28.15 total
On FreeBSD:
Oops! I left that out:
$ time /tmp/cdbf /var/tmp/invoice.dbf /dev/null
/tmp/cdbf
On Jun 11, 2008, at 12:42 PM, Kirk Strauser wrote:
I'm almost ready to give up on this. I've gone as far as completely
rewriting the
original C++ program into straightforward C, and still the
performance is terrible on
FreeBSD versus Linux.
On Linux, GNU libc buffers file data much more
Kirk Strauser wrote:
Kris Kennaway wrote:
I don't understand what you meant by It's also doing a lot of
lseek()s to what is likely the current position anyway (example: seek
to 0x00, read 16 bytes, seek to 0x10, etc.). then.
I just meant that 16 was a smaller number than 4096 to use in an
I'm running a command (dumprecspg from my XBaseToPg project) on a FreeBSD 7
server. I've noticed that throughput on that program is a lot lower than I
would have expected, and further investigation found it spending most of its
time in the kernel, presumably in read() [1].
I was testing the same
Kirk Strauser wrote:
I'm running a command (dumprecspg from my XBaseToPg project) on a FreeBSD 7
server. I've noticed that throughput on that program is a lot lower than I
would have expected, and further investigation found it spending most of its
time in the kernel, presumably in read() [1].
On Thursday 05 June 2008, Kris Kennaway wrote:
Kirk Strauser wrote:
ktrace(1) and check for the buffer size in use. It is probably too
small.
Kris
It seems to be doing a lot of read()s with 4096-byte buffers. Is that what
you mean? It's also doing a lot of lseek()s to what is likely the
Kirk Strauser wrote:
On Thursday 05 June 2008, Kris Kennaway wrote:
Kirk Strauser wrote:
ktrace(1) and check for the buffer size in use. It is probably too
small.
Kris
It seems to be doing a lot of read()s with 4096-byte buffers. Is that what
you mean? It's also doing a lot of
Kris Kennaway wrote:
No, if it's reading in 16 byte units it will explain the terrible
performance.
No, it's actually doing 4096-byte reads. That was just an example of
what I meant. Since I wrote that, though, I wrote a program to do
1,000,000 seeks to position 0, and it ran immeasurably
Kirk Strauser wrote:
Kris Kennaway wrote:
No, if it's reading in 16 byte units it will explain the terrible
performance.
No, it's actually doing 4096-byte reads. That was just an example of
what I meant.
I don't understand what you meant by It's also doing a lot of lseek()s
to what is
Kris Kennaway wrote:
I don't understand what you meant by It's also doing a lot of lseek()s
to what is likely the current position anyway (example: seek to 0x00,
read 16 bytes, seek to 0x10, etc.). then.
I just meant that 16 was a smaller number than 4096 to use in an
example. :-)
But
12 matches
Mail list logo
