From: pharrington Date: 2009-08-20T14:50:13+09:00 Subject: Re: Confirm my Performance Test Against Java? > pharrington, in your response you stated: > > "as the code that happens is neither the most "elegant" *nor* fastest > Ruby can do." > > Can you please provide me a re-write of the Ruby code I used that is > elegant and fast so I can learn from you? Hi, I was gone for the day, but numerous people in the thread already did both, so :) > @Mike > > Thank you for providing the Gist link to a file. > (http://gist.github.com/170476) > > However, the changes don't improve the performance when I take into > account what was removed and I had in there on purpose. Take note of > item #2 below. > > 1) Object structure > > The modified code removed all of the class/object structure, which I > purposefully had in there to simulate this being an object within a > larger project. Sticking methods in a class really doesn't simulate an object in a larger project at all; its just methods in a class. The general concept of ***larger project*** isn't really something you can factor out; its just how the code ends up needing to be structured for the task at hand. > That being said, converting the lines of code we're discussing for > performance into a script means nothing to this discussion - but I > purposefully am writing the code in an OO style with classes as opposed > to scripts. Again, coders code to solve the task at hand. When you say "Yes, this test is representative of some of the types of applications and necessary data processing I have current applications doing and am needing in some future ones" we look at what the code *does*, not guess at a vague idea of a large project which defining a class is apparently supposed to imply. The code you posted counts words in a file. Nothing more; nothing less. > I was also purposefully making the Java and Ruby versions as similar to > each other so as to allow a performance comparison to be done with as > little difference as possible in approaching the code. If you want to write Java code, then why use something that isn't Java? This is like taking a C program, trying to emulate as closely as possible, line-for-line the C code in Erlang (using mutable data and everything) and then dismissing Erlang because it's worse at being C than C. Different languages express solutions to different problems in different ways; that's the whole point. I guess you just wanted to know whether or not the Ruby interpreter is generally slower than compiled Java bytecode? Of course it is (I assumed this was common knowledge (to the point of being a cliche even) but :\). If anyone told you otherwise, I'm sorry you were blatantly lied to. BUT Ruby lets us *produce* faster and more accurately, giving us plenty of spare time to optimize the code (even porting specific parts to C if needed) after we've easily made it correct. > 2) Counting versus Using the Tokens > > In the modified code, it is now just counting the tokens: > >     num += l.split.length > > Obviously that is faster than what I had in the original code. Again > however, I'm doing this on purpose. > > Counting the number of tokens in an of itself is not all that I was > doing in the original code or in the Java version. To simulate more > closely what actually occurs in a functional system I am: > > - assigning the array of tokens to a variable > - iterating the tokens to do something with each of them > > In this case I'm just assigning each token to another variable and then > performing the count. > > In a real world use I'd perform some function on the text, put it > somewhere, whatever. In the real world, the "do something with each of them" is the real juicy part that we want to compare. What is the something? Does the real world program just end up counting tokens? Then we realize this, count tokens, and be on our merry way. Is the real world program taking each word in a text file, comparing relationships against a lexical database, then based off whatever relationships in context and calculations constructing a sort of hash to classify a given text document? String token = tk.nextToken(); numTokens++ does not begin to describe or "simulate" this, so what is the point of the benchmark? > This change accounts for the difference in time from "7965.289 ms" to > "4821.399 ms" when I run the original code and the modified code. > > So yes, the modified code is "faster", but it's not doing the same thing > as the original and therefore not a valid comparison. The input is the same. The output is the same. The person running your code does not care if its object-oriented, procedural, a script, is functional, etc; he only cares if he gets the expected output in a reasonable amount of time when he gives his input. Thus the coder only cares if she can code fast enough to give the client the features he wants, and if she can does this in a way thats easy to keep up with his increasing feature demands while keeping the code stable and fast. But I dunno, maybe I'm still completely missing the point?