> Or the parser could do something similar on the fly: if a token is 
> matched, move it to the front of the list. Tokens that occur more often 
> will spend more time towards the front of the list. Not as efficient, 
> but simpler and adapts to the scene...for example, a mesh file will have 
> a very different occurance distribution from other scenes, mainly having 
> "triangle" or "smooth_triangle", "{}" braces, ",", "<", and ">" 
> characters, and numbers. After the first triangle, these will be at the 
> top of the token list. I did something similar for Sapphire: when a 
> symbol is resolved it moves to the front of the symbol table.


	Do you mean that the current POV-Ray parser (which I never
really investigated) searches the full list of keywords to get the
proper token ? If so, what about hash tables as used when parsing
mesh triangles/textures ?
	Putting the last resolved symbol at the beginning of the
list assumes a high probability to find the same symbol again. I
agree this is good for such big objects as meshes (and usually
a very big scene is made of very big meshes...). But I don't think
it's better than using hash tables in general. [A perfect hash table
would be appropriate for build-in keywords which number is fixed].

	Forget all that if POV-Ray does it already  :-)

Post a reply to this message