First of all, to even consider code size makes me wonder about the goals of the original author. Complexity and readability are critical, but they have virtually no relationship to code size. The only time you would want to consider code size without other variables would be to promote a language.
In fact, if you count all the utilities that the ruby solution uses, it’s probably thousands of line of code long. If I write and use a utility, I can make my code much smaller than that ruby solution! Or is there some arbitrary rule that nothing counts if it ships with the language?
I haven’t seen anyone approach the real problem–the fact that all the solutions I’ve seen move text, and most read text in a line at a time.
If you really had to speed it up, there are some definite areas to attack:
- read the whole thing into a buffer at once. Use a call that makes use of DMA if you have control of that.
- Run through the buffer without moving code/creating objects for each line.
- Avoid regular expressions.
You probably jumped straight to “Oh, that’s complicated. Lots more code”. If you write your code correctly, it will be longer (should be), but it should also be more readable than the ruby code above. The main function would probably be cleaner because the sub-functions you use will be tailored to your requirements, not generic in-language solutions.
- If you still want to go multi-threaded, calculate the center of the buffer and search for the first carriage return after it; mark that spot. Pass a pointer to the buffer and an index/length of each half to different threads.
If you want to use more than two threads, just recurse.
See, the real problem here is the language. Ruby and all these other “Elegant” languages give you these tricks that make you think you are implementing a great solution because your ruby code looks small, but actually these tricks often lure you into a pretty poor solution that no good programmer would use if he could actually see what he was doing.
I’m not saying optimizing is a good idea–it’s a last resort; and if ruby is fast enough for you and you feel it makes you code faster–great…
But I also really agree with the callout in the article saying that it’s an illusion. Personally I worked with Ruby for a year and never got the hang of it–I can’t read the example given because I forget all the tricks.
I prefer a language with as few surprises, syntactical exceptions and tricks as it can possibly have. Explicit, clear, long (if necessary) code is fine. I can type a lot faster than I can troubleshoot someone elses’ “Short” code, and if the code is done right, there is no reason any given method should be significantly longer.