Some benchmarks of my own, using my most common use case DataMapper: A Merb app.
Using a flat merb app http://gist.github.com/gists/31431 First part is a simple model class, no ORM involved. We call one method on it that returns false, and another that raises an exception. Second part is a simple DM model, using the do_sqlite memory adapter. We try to save an invalid record (missing name). The first one just does a save, which returns false. The second one is a hypothetical #save! that raises something if the save failed. Both of these just return a string, and don't go through merb's exception handler. Executive Summary: req/s % No Exception 511.73 1 Exception 492.33 1.04 ORM – No Exception 403.59 1.27 ORM – Exception 532.31 0.96 Somehow, with the ORM, raising an exception is actually faster. Don't ask me why. All of this is a moot point, however. I will be checking the return value of save, and raising an exception. It would just be simpler for me if the ORM did that on its own. Yes, raising exceptions may be slower, but compared to the overhead of establishing an HTTP connection, routing the request, and initializing models, I just really can't be bothered with a speed difference so small, I can't measure it reliably. Certainly not if it makes my job as an application developer harder. Paul s.ross wrote: > I'm starting to be persuaded... However, > > 1) Don't think there is no performance penalty. There is. > 2) Java is slow. Everything is relative and when you are using an > interpreted language Java looks fast. Solution: Make faster hardware. > > What begins to sway me to the exceptions point of view is the concept > that we should optimize for the programmer and not the computer. I'm > still not sold on exceptions being in the ORM and particularly not > inconsistently as in ActiveRecord (some things return object/nil, > others raise exceptions). > > Finally, there are benchmarks to support any point of view, and FWIW > here's another one. Of course the code is trivial and the expense of > the method invocation and the exception handling are all that are > measured here. Clearly, this is a fiction never duplicated in real > code. It does, however, allow you to understand that the cost of > raising an exception is over 8x the cost of returning a value (on my > MBP). > > > require 'benchmark' > > class BozoException < Exception; end > > class TestException > def something_risky_with_exception > raise BozoException.new("Bozo raised an exception") > end > > def something_risky_without_exception > return BozoException.new("Bozo raised an exception") > end > end > > n = 10_000 > > test = TestException.new > > Benchmark.bm do |x| > x.report('using exceptions: '){ n.times{ > begin > test.something_risky_with_exception > rescue BozoException => ex > ex > end > }} > x.report('not using exceptions:') > { n.times{ test.something_risky_without_exception }} > end > > user system total real > using exceptions: 0.160000 0.020000 0.180000 ( 0.182851) > not using exceptions: 0.030000 0.000000 0.030000 ( 0.023572) > > > On Dec 2, 2008, at 1:43 PM, Vivek Sharma wrote: > > > > > Folks, I think I'm going to have to side with Alex on this one. Let's > > clearly state the problem: > > > > "Sending a return code back rather than an exception causes a certain > > amount of opaqueness in the code. It's becomes impossible to know the > > real details of an error." > > > > IMHO, I also think that adding all of these validation checks around > > the error is very un-DRY. It makes a lot of sense for me to have the > > ORM handle this. > > > > I think the argument against exceptions finally comes down to this: > > > > "We will take a huge performance hit for using validation exceptions. > > Therefore we won't do it." > > > > A couple comments: > > > > 1.) Java ORMs make use of exceptions all the time and no one would > > accuse Java of being slow. > > 2.) I thought the goal of an ORM was to optimize for developer time > > and to help them stay DRY. > > > > It seems to me that if there really are huge performance issues with > > Ruby's exception handling then that's where the energy should be > > dedicated and it should be fixable (as shown by Java). > > > > -- Vivek > > > > On Dec 2, 3:53 am, Alex Neth <[EMAIL PROTECTED]> wrote: > >>> I think we need to agree to disagree on this one. I'm not as up to > >>> speed on Ruby's exception structure as C-like languages, but it > >>> stands > >>> to reason that there would be similarities. Every time an exception > >>> context is established, a set of unwindable frames need to be > >>> created > >>> so your program can basically perform a non-local jump outside its > >>> current execution context while at the same time cleaning up objects > >>> left lying around unfinished all the way up the call stack until the > >>> exception is finally handled. Garbage collection simplifies this > >>> immensely, but doesn't make the overhead go away completely. You > >>> are, > >>> therefore, suggesting an implementation decision at the ORM level > >>> that > >>> is more memory-intensive and cpu-intensive strategy than simply > >>> returning values. > >> > >>> In many ways, merb *is* a good model because they have tried to make > >>> implementation decisions (down to what ORM if any should be used) > >>> that > >>> could sensibly be decoupled from the framework easy to decouple. > >>> That > >>> might be a good way to look at error propagation strategies. I think > >>> DataMapper is currently at a point where it is not tied to Ruby's > >>> exception handling. If that's part of your implementation strategy, > >>> wrappingsave! (as was previously suggested) is one option. You could > >>> also fork the project and implementsavein your preferred style. > >>> You'd probably get most of the goodness of the project in merges. > >>> And, > >>> you might be right.Exceptionsmight be superior in all ways to simple > >>> error returns. That's what's great about Open Source: You can have > >>> it > >>> your way and if your was is a better one, people will recognize > >>> that. > >> > >> As far as the mechanism ofexceptionsbeing expensive, I'm not sure > >> that's inherently so, although that implementation level of the > >> language is not an area I'm an expert in. > >> > >> There is no reason for it to actually assemble a string backtrace > >> though until backtrace is called. It seems would only need to store > >> some sort of stack reference. I'm not speaking from a compiler > >> background though. > >> > >> I am quite convinced that in this case of DM,exceptionsare > >> superior. I'm not sure at this point it justifies me maintaining a > >> fork. I was hoping to get my position out there. Perhaps it will > >> come > >> up again. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
