On 3/11/21 9:34 PM, Christof Ressi wrote:
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")
funnily enough, this was exactly the line that triggered my query. how did you know? (probably because you checked the background of my other post)
is my all means worse than
!strcmp(flag, "-lib")
well, no. all those specific comparisions for "-lib" are done in loop, so you would probably put the gensym("-lib") outside of that loop.
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.
i just find the code mostly more readable. `!strcmp(flag, "-lib")` is of course fine (apart from the inverse logic of strcmp), but `!strcmp(argv[i].a_w.w_symbol->s_name, ">")` is not. in this case i would happily swap that for a slow `(gensym(">") == atom_getsymbol(argv+i))`.
anyhow, most of those symbols (with the exception of the actual flags), are also Pd-objects, so the symtable pollution shouldn't really matter.
gfsmdrt IOhannes