On Wed, May 19, 2010 at 5:15 PM, pancake <panc...@youterm.com> wrote:
> i dont see the point of having:
> char *moo(){
> char *foo;
> foo = strdup("bar");
> return foo;
> }
>
> when you can have:
>
> char *moo() {
> return strdup ("bar");
> }
Tail recursion indeed looks elegant, but doesn't check for NULL, so
you need a named variable anyway. You, however, want to use one
variable for different purposes. (What a hypocrite I am! I'm doing it
all the time in other places. Why do I keep arguing?) I guess I agree
with you.
>> > 7)
>> > I would change --force flag check to be just '-f'
>>
>> A matter of taste.
>
> in suckless, getopt_long should not be used.
Indeed I don't use getopt_long.
>> > 9)
>> > as all filepaths are of similar size you can just allocate blocks of this
>> > size
>> > and index by using a multiplier which results faster than having many
>> > chunks
>> > (with some tests i did in 'alt' (hg.youterm.com/alt) this kind of
>> > optimizations
>> > result in 3-5x faster execution.
>>
>> And would also add much confusion to the reader (and, judging by the
>> mailing list, our readers seem to have sensitive eyes).
>
> it's not that 'complex'. code shouldnt look uglier with this change, it's
> just to
> replace current allocator, which you should do, because failed mallocs must
> die().
Care to write a patch to prove your point? I must admit I've never
written my own allocators.
> Another optimization you can do is to remove the 'free()' part. It's useless
> and
> slowdowns the execution. The kernel already frees the heap of the process on
> exit(), and it's not a program that will run forever. Only until the end of
> the
> execution.
>
> This change will also speed up the execution.
Hmm. This claim sounded unfounded, so I just benchmarked it. I'm
surprised to admit that you were right.
The reason for free()s, however, was not conserving memory, but valgrindability.
Elmo
