Re: [dev] dmenu_path rewrite in C

On Wed, May 19, 2010 at 5:15 PM, pancake <pancake_AT_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
Received on Wed May 19 2010 - 14:55:30 UTC