[PD-dev] symbol comparison vs strcmp()

Christof Ressi info at christofressi.com
Thu Mar 11 21:34:54 CET 2021


> the main purpose of the the symbol table is, as i understand it, to 
> make string comparison super-fast (as there's no need to compare each 
> character but just a simple address). 
It is only fast if both sides are `t_symbol *`, but if one side includes 
a call to gensym(), it will be *slower* than a simple strcmp()!

For example,

flagsym == gensym("-lib")

is my all means worse than

!strcmp(flag, "-lib")
  

> looking at the code i see quite a number of places¹ where something 
> like this is used: 

The vast majority of the cases I've found are in settings/flag parsing.

First of all, these are not the performance critical parts of Pd and 
most of the strings in question are very short, anyway.

Secondly, for symbol comparison to make sense, you would have to create 
all those symbols upfront and store them somewhere. This would indeed 
pollute the symbol table and add many lines of extra code for no real 
benefit.

> or should they just be replaced with symbol comparisions? 
I'd say: no :-)

Christof

On 11.03.2021 19:26, IOhannes m zmölnig wrote:
> hi all,
>
> Pd uses a symbol-table for practically all of its string handling.
> the main purpose of the the symbol table is, as i understand it, to 
> make string comparison super-fast (as there's no need to compare each 
> character but just a simple address).
>
> now, looking at the code i see quite a number of places¹ where 
> something like this is used:
>
> > strcmp(atom_getsymbolarg(i, argc, argv)->s_name, refstring);
>
>
> what is the reason for this?
> is it just out of habit (because in all the other projects you usually 
> use strcmp())
> or because this is an attempt to not pollute the symbol table needlessly?
>
> or am i missing something?
> or should they just be replaced with symbol comparisions?
>
> gmsadr
> IOhannes
>
>
>
> ¹ i've counted about 135 of such uses (automatically; so I certainly 
> missed a few)
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210311/c483a728/attachment.htm>


More information about the Pd-dev mailing list