No were are working on the basis he has already has 1 gig to write.
You won't be able to write a program which writes it faster than mine.
Printable View
Come on! A utility function that has the file name hard-coded? A utility function that is ready to simply throw away 4 GB of data if some error opening the file happens? Hard-coding the name doesn't protect you here, what if the file exists and is read-only?Quote:
Mine is an example of programming of the very highest standard possible infact.
May-be there should be a competition? But rather than just writing 1 GB of meaningless data, lets open a 1 GB file, do some simple math and write the results out?Quote:
You won't be able to write a program which writes it faster than mine.
> I was therefore giving an example of how to write the data at 'top speed'.
Unless you really have an OS which can cope with it, and that much real RAM in your machine, your "fast" data is going to wind up spending most of it's time in the swap file.
The smallest common multiple of BUFSIZ and the cluster size of your file system would be my guess. As soon as the disk seeks to another cluster, all pretence at "maximum" performance is gone.
Don't worry too much Elysia, esbo has a history of spew. Personally, I thought he'd gone for good, or at least learnt something.
http://cboard.cprogramming.com/showthread.php?t=82909
http://cboard.cprogramming.com/showthread.php?t=82858
http://cboard.cprogramming.com/showthread.php?t=82351
http://cboard.cprogramming.com/showthread.php?t=82440
And there are plenty more examples. Nearly every senior member has at some time been in some kind of slanging match trying to hammer a point home.
I smell some benchmarks.
It's indeed faster to read once and write once, IF you have the memory, that is.
Otherwise it will all end up in the swap file and you're literally reading and writing the file twice.
Well, anyway, let's ignore esbo and the spew of someone who obviously do not know the spew he/she/it is spamming.
You should not put exit in that function because you might want to use it in another program later. If you didn't, you might as well not use a function and put it all in main.
You should not use a buffer that large because it takes up a lot of memory that other programs might want to use.
If you use a large buffer, it should be dynamically allocated so that it doesn't crash the stack.
Exit is in the function because it is a sensible place to put it.
If wanted to use it in another program I would also want the exit in there too
so it would be pointless taking it out to then have to but the same frigging
code back in again would it not? Which also increase the chance of making
a coding error rewriting it.
The buffer is large because I am assuming a large buffer is required.
The code is originally from a program which requires to access a large amount
of data randomly at top speed. Thus it must all be in memory.
How can it be 'dynamically' allocated when it is required all the time?
How can it crash the stack?
It has never crashed the stack and it never will.
>Exit is in the function because it is a sensible place to put it.
I disagree. Why do you think it is a sensible place to put it?
>If wanted to use it in another program I would also want the exit in there too
so it would be pointless taking it out to then have to but the same frigging
code back in again would it not? Which also increase the chance of making
a coding error rewriting it.
why not just:
?Code:function();
exit();
>The buffer is large because I am assuming a large buffer is required.
Why is a large buffer required? Have you tried a smaller buffer, say one of BUFSIZ type? What was the speed difference? Why was that difference not suitable to your application?
>The code is originally from a program which requires to access a large amount
of data randomly at top speed. Thus it must all be in memory.
Does it all need to be in memory /at one time/? Why?
>How can it be 'dynamically' allocated when it is required all the time?
I don't understand the question.
>How can it crash the stack?
If it was a local variable like it is supposed to be, then it would be allocated on the stack, and since the stack is usually small in size, it would not be able to contain your variable.
>It has never crashed the stack and it never will.
Actually, you are right on that part... I didn't notice that it wasn't actually on the stack. However, consider that the computer does not have the memory for that. Then the program would abort before it started, but what would the return code be?
If it cannot open the file it cannot run.
The only logical thing it can do is to exit, which is exactly what it does.
It also makes the main program look nicer, uncluttered with error handling, easier to read.
The same would be true in if it was used in other programs, also you only have
to write the error function once, not several times - less work, less chance of making
a coding error.
It all needs to be in memory because fast access is required.
It would be very slow if disk I/O needed to take place to access a part of the
buffer.
It also makes the code much simpler. The entire buffer is read or written in one line of code.
No loop required. Hence no loop counter. It is smple and efficient.
QUOTE=robwhit;704298]
>>How can it be 'dynamically' allocated when it is required all the time?
>I don't understand the question.
Not sure I understood yours either.
>>How can it crash the stack?
>If it was a local variable like it is supposed to be, then it would be allocated on the stack, and since the stack is usually small in size, it would not be able to contain your variable.
I don't want it to be local because there is no benefit in making global data local.
>>It has never crashed the stack and it never will.
>Actually, you are right on that part... I didn't notice that it wasn't actually on the stack. However, consider that the computer does not have the memory for that. Then the program would abort before it started, but what would the return code be?
I don't create large amounts of storage of the stack hence I don't get exotic memory faults
so I don't need to worry about such things.
I avoid creating variables on the stack like the plague is just asking for trouble.
I will use a few local loop counter and sometime some other variable which I know
will only ever be used locally but other that that I make stuff global.
It makes things so much easier. It also makes debugging easier, a program can cope better
with corrupt data than with a corrupt stack.
But it would make the function cleaner.but suppose that I wanted to make 5 files that had that content? How would I do that? the function would exit every time.Quote:
The same would be true in if it was used in other programs, also you only have
to write the error function once, not several times - less work, less chance of making
a coding error.
And what error would the compiler not be able to catch with a snippet that small? Would you really not be able to see it with just a casual glance over the code?
Fast access from what to what?since the buffer is in memory, the only way that you would need disk I/O to access the buffer is if the buffer was in swap space, which would be more likely with a larger buffer.Quote:
It would be very slow if disk I/O needed to take place to access a part of the
buffer.
The time it takes to increment a counter is microscopic compared to the time it takes for disk i/o.Quote:
It also makes the code much simpler. The entire buffer is read or written in one line of code.
No loop required. Hence no loop counter.
I think that if a function does one thing, it's simpler than if it does two.Quote:
It is smple and efficient.