Not sure it's really a science, look more like a collection of recipes to me ;o) With a real science you have preditable results, not with computers (even if in most cases "it works"). There are some good theories but what's really new since Turing machine (joking) ?
Did you know that for each MS developers there are more or less 5 to 10 testers ? Nasa is at least 100 for a developper (not sure about this numbers, just hears about them) ! Jacques PS : seems we need some fun... De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > Cool. Reminds me of the controversy over using antiseptic to aid open wound > healing. > > Most antiseptics were tested in vitro. In vivo tests results recently show > marked differences from > prior in vitro results. > > Hmm. Example... say... PVP-I and cadexomer iodine. PVP-I with low > concentration actually boosts > bacteria growth in open wounds! High concentrations kill repair cells. > Curious how science is so > very very inaccurate, especially in in vitro tests. :) I'm still looking for > published results for > the newer cadexomer starch form. > > Please don't reply. Totally off-topic. Just thought David crafted a cool > explanation of the > science of computing. > > Jonathon > > David E Jones wrote: > > > > It is actually a pretty big deal, and there are very good reasons it was > > integrated into OFBiz. In OFBiz we deal with LOTS of temporary objects, > > especially Maps and Lists, and when doing performance profiling you can > > see the impact of this in the results (ie lots of time creating objects > > and allocating memory, lots of work for the garbage collector to do when > > destroying objects and un-allocating memory). Because of this it makes a > > big difference to use recycled objects like the Javolution FastMap and > > FastList, ie calling FastMap.newInstance() to get an object out of the > > pool of existing FastMap objects rather than calling new HashMap() to > > create a new HashMap each time. > > > > There are actually lots of performance tricks that OFBiz uses, though > > most of the work was done before most of the people now involved with > > OFBiz were around. Early on I spent a few weeks profiling and tweaking > > over the course of a few months as things were being heavily developed. > > Our classpath caching, special purpose internal methods in the entity > > engine, and the use of Javolution for the Fast* objects and for object > > recycling for often used but short-lived things like the GenericValue > > object (which is a recycled object) are all results of that effort. > > > > For other things like get and put operations on a FastMap versus a > > HashMap... I wouldn't expect a whole lot of difference. It may be that > > FastMap does a better job of managing large and scattered hash arrays or > > something but there is really only so much you can do with that as those > > algorithms have been around for a LONG time and have been thoroughly > > reviewed and refined by lots of people. To really get an understanding > > of this would require a bit of research, but it's all very standard > > computer science stuff, so the material is readily available and very > > accessible if you get a decent book or whatever. It is nice stuff to > > know about because these basic data structures and algorithms are what > > everything is based on in modern software and understanding them makes > > it way easier to understand performance impact and interpret the results > > of profiling, as well as understand higher level algorithms and data > > structures like those used in relational databases and such. > > > > Knowing all of that stuff is of course not a substitution for using a > > profiling tool, and in fact those who really understand the stuff know > > all the more how important it is to use profiling tools. The nature of > > the software is that it is very complex, and even if you know it all > > it's hard to remember and grok the importance of certain pieces > > sometimes. In other words it's deterministic, but complex. The most > > experienced people will know that they might be able to guess really > > well and understand really well the general things that might impact > > performance, but until you do profiling and tweaking to see a > > performance difference they are only guesses and guesses aren't proofs, > > and aren't enough if you're trying to be careful and make a real > > difference in something. > > > > In short, doing profiling is great and extremely valuable, as is > > understanding the underlying data structures and algorithms. However, > > neither of them along is sufficient to really understand and describe > > why something is performing a certain way or make a difference in how it > > performs. > > > > -David > > > > > > On Dec 14, 2007, at 1:28 PM, Jacques Le Roux wrote: > > > >> Sumit, Adrian, All, > >> > >> I had a cursory look at it. In abstract, yes this seems to be right > >> > >> Though those lines you took from Google are 4 years old > >> http://www.javalobby.org/java/forums/t9377.html?start=15#reply20 > >> > >> Anyway it seems to be right, here the answer from Javolution Creator > >> (JM Dautelle) > >> The best analogy between FastMap and HashMap would be buying versus > >> renting. With FastMap you pay upfront but you are done with it. > >> With HashMap you pay each time you "put" a new entry (not only when > >> you allocate but also later with the GC interests...). Obviously > >> if you intend to sell your house three months later it does not make > >> sense to buy it. > >> > >> Also interesting is JM Dautelle's this note found at > >> http://javolution.org/doc/benchmark.html > >>> Although it looks nice, I see that some of your collection classes > >>> are not always faster than their Java 6 counterparts. > >> <<Some classes are faster, others are slower (for example > >> ArrayList.get(int) is faster with the -server option, slower without it). > >> Overall, there is no significative difference in average execution > >> time. The main advantage of Javolution collections is that they > >> are time-deterministic (the maximum execution time is very close to > >> the minimum execution time) and they are RTSJ-Safe. > >> They have some additional characteristics such as thread-safe without > >> synchronization, support for custom key/value comparators, > >> direct record iterations (faster than iterators), recyclable, reduced > >> impact on GC (fragmentation or large arrays allocations), > >> support for custom entry implementation (FastMap) or custom node > >> implementation (FastList), etc.>> > >> > >> See also > >> http://noctarius.l2castell.org/download/benchmark_trove_javolution_java.pdf > >> > >> > >> Maybe knowning the real reason(s?) it was integrated in OFBiz would be > >> cool, does not look like a big deal tough, am'I wrong ? > >> > >> Jacques > >> > >> De : "Adrian Crum" <[EMAIL PROTECTED]> > >>> I just spent some time running performance tests on FastMaps and > >>> HashMaps. Calling the get methods > >>> showed no speed difference. The Javalution classes seem to have a > >>> speed advantage in building Maps > >>> and Lists. They claim their FastSet.removeLast method is faster than > >>> the Java library. So, there is > >>> a speed advantage in certain scenarios, but not in all cases. > >>> > >>> -Adrian > >>> > >>> Sumit Pandit wrote: > >>> > >>>> *i have a question please make me correct if i am wrong :-* > >>>> > >>>> if we compare FastMap Vs HashMap, > >>>> > >>>> *FastMap is faster than HashMap so long as the map is long lived and > >>>> relatively predictable in size. If you try to use it as a short-lived > >>>> general replacement for HashMap it may very well kill your performance. > >>>> > >>>> *I found these lines some where in Google. > >>>> so does it mean that we should use HashMap for local variables ? > >>>> > >>>> Also please explain me the performance issue if we use HashMap > >>>> rather then > >>>> FastMap. > >>>> > >>>> Thanks for suggestion. > >>>> > >>> > >> > > >
