Given time, I can concoct a test case where the percentage of equals varies between 0 and 100%. But whatever these results might be, I think that the findings up to now indicate that collectSet should be left as it is, and any desire for a different behaviour should be satisfied by a separate accumulate function, say, collectBag, returning the key set of an IdentityHashMap. (Clarifying the reasons of the implementation differences might be interesting.)
-W On 1 March 2012 00:11, SirMungus <[email protected]> wrote: > > SirMungus wrote > > > > So, there would undoubtedly be a performance impact, even not taking into > > account the "new HashSet()" in the getResults() call. Whether it would be > > significant enough in real world scenarios to warrant a much more complex > > implementation requires more knowledge of Drools's user base than I > > possess, for sure. My guess is that Wolfgang's second scenario above is > > generally unrealistic. But, if it is routine for rules with collectSet() > > to end up with sets involving thousands of objects like the /second/ > > scenario, that could certainly be an issue. > > > Goodness. I meant to say that the first scenario (instead of "second" > italicized above) could potentially be realistic. The larger the sets, > larger the penalty each time getResults() is called. > > -- > View this message in context: > http://drools.46999.n3.nabble.com/BUG-5-3-0-Final-CollectSetAccumulateFunction-should-probably-use-IdentityHashMap-internally-tp3774079p3788970.html > Sent from the Drools: Developer (committer) mailing list mailing list > archive at Nabble.com. > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
