On 18/01/10 08:13, svn commit wrote: > RuleFileReader.optimiseAndSaveBinaryOp(): Try to be symmetric. > optimiseAndSaveAndOr(): Refactored from optimiseAndSaveBinaryOp().
So you are trying to transform a=b & (c=d|e=f) to a=b&c=d | a=b&e=f The second.isType(OR) will not be executed because first.isType(EQUALS) will have matched first. Also it is not so clear that it is an optimisation as both the new rules will be under the same search key and so you will end up doing pretty much the same thing in either case. With the OR first they will be under different search keys and so will reduce the work in some cases. But more importantly it is *necessary* to deal with the case where the OR comes first because the first term has to be an EQUALS or EXISTS. Symmetry does not apply as the situation is asymmetrical to begin with, and there is no such requirement on the second term. ..Steve _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
