[Melbourne-pm] Still performing well..
Daniel Pittman
daniel at rimspace.net
Wed May 19 21:32:32 PDT 2010
Sam Watkins <sam at nipl.net> writes:
> On Wed, May 19, 2010 at 03:20:28PM +1000, Daniel Pittman wrote:
>
>> Well, not entirely: I just think it will make the performance curve of your
>> application look poor once it gets asked to process a 4GB CSV file, while
>> languages that do free unused memory will do a little better. :)
>
> Well it depends whether you actually need to keep all the data in memory.
That is a fair point. :)
[...]
> Stream processing is a different thing. Nicely written C performs much
> better than any interpreted language or bytecode/JIT language for both
> stream processing and loading.
Well, generally. Hand-tuned assembly code often beats the portable assembly
of C at the same job, too. I don't know I would stick with the statement
forever, though, especially if the stream processing was complex and had many
decision points.
> I don't know of any compiled language that performs better than well-written
> C for many cases, because C is close to the metal, and allows the programmer
> to do things their own way.
...and, just to check here, you are only counting "C that is written well",
not "C in the hands of a random programmer", right?
> For example with stream processing, I commonly use a single resizable buffer
> for each line, so there is no need to free anything inside the loop. You
> said that I am cheating by not freeing anything, but if I write my C (or
> brace) code well, there is no need to malloc or free anything except perhaps
> a single line buffer, and maybe realloc it a couple times if it started off
> too small.
Yeah, and your VM language is going to do the same thing: use a static buffer,
get static buffer performance. Witness, for example, Perl. :)
> Going nuts with malloc and free for every field in a file is almost always a
> bad way to program in C. In Java, perl, python, etc., you really have
> little or no choice about that, there's no nice way to do it as efficiently
> as in C, you need to use an object / buffer for each string.
Nonsense:
my $x = '.' x 10000; # preallocate
sysread(FH, $x, 5000); # ...and use that storage
Feel free to verify my claims, if you wish. :)
Daniel
--
✣ Daniel Pittman ✉ daniel at rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
More information about the Melbourne-pm
mailing list