> I didn't say it was impossible. Just that in this case, the code gets > slowed down in convoluted loops everywhere. Also I feel that clear, > straightforward code is much easier to write, debug and get confident > with and often much faster.
I bet it's all your mind experiments without a real benchmarking. You're talking about "easier to write", "fast" code "without any loops" because you're using intensively calls to realloc() and strcmp()? realloc() is a pretty heavy function call for the comparing of two strings. realloc() by itself involves a lot of code with different loops and mutexes (which is a bottleneck in multi-threaded applications). So essentially you hide away all loops from your code, move it into some library code you don't have control on and so losing all control over the performance of your own code... My 2 cents here is: sometimes bigger and more complicated code runs a whole lot faster than simple one if the speed is a real concern of course... Pavel On Sat, Oct 3, 2009 at 8:09 PM, Jean-Christophe Deschamps <[email protected]> wrote: > Igor, > > ´¯¯¯ >>It seems fairly easy to me to >>implement the kind of collation you describe using only a fixed amount >>of extra memory. > `--- > > I didn't say it was impossible. Just that in this case, the code gets > slowed down in convoluted loops everywhere. Also I feel that clear, > straightforward code is much easier to write, debug and get confident > with and often much faster. > > > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
