Frisky <Frisky_NOSPAM@NorthPole.net> wrote:[color=blue]
> At this point, I think we have beaten this horse to death.[/color]
Perhaps. It looks like I'm not going to persuade you that exceptions
really *aren't* a performance problem in reasonable real world apps,
and you're not going to persuade me that they are...
[color=blue]
> However, we have not yet achieved the maximum number of posts, the maximuim
> depth on a post, or maximum number of bytes in a reply either. So, nntp on
> dude ... :)[/color]
Well, this set of posts will be the last for the night from me - it's
already past midnight here, and I'm sure my little boy will be getting
me up in about 6 hours...
[color=blue][color=green]
> > I'd say that's the exception (no pun intended) rather than the rule
> > though.[/color]
>
> It does not make it any less viable a tactic. For resources though, I am
> with you. That was purely based on need. As explained.[/color]
After prodding though - it was still the solution you suggested to the
OP :)
[color=blue][color=green]
> > So in this one odd situation, it's the better solution - but I wouldn't
> > suggest using it normally.[/color]
>
> Funny, but I just use the methods that throw when I need that, and the
> methods that return null when I need that. Neither is better than the other.
> They just have different uses.[/color]
That's because you dislike exceptions though - when using exceptions is
the normal, idiomatic way of showing a very unexpected situation (such
as a resource being missing), they look very different.
[color=blue][color=green][color=darkred]
> >> Again, refer above to the application for this was written.[/color]
> >
> > That's not the app you were giving advice for though :)[/color]
>
> Actually, I was not giving advice on an application. The questions was,
> (para-phrased) files have been added to the project, but I don't know how to
> access them. My code suficed this answer and showed some quasi
> implementation. And with the message "does this help?" I think it answers
> the question fine. (Other than my mistake of grabbing only part of the code
> out of a huge utility class in an attempt to be quick.)[/color]
In my experience, people tend to use code they're presented with,
whether it's actually suitable or not, unfortunately.
[color=blue][color=green]
> > And the point is that in practice you *don't* actually throw a lot more
> > of them. As I said above, if your app is *actually* throwing that many
> > exceptions, it suggests deeper problems where you shouldn't be using
> > exceptions. The reason for not using exceptions in that case isn't
> > because of performance - it's because you're clearly not handling an
> > exception case, you're handling a common one.[/color]
>
> Depends on the application. If we are sticking to the resource theme, most
> applications would not have had as much code as we've written to this
> newsgroup in them. :) Much less have a need to worry over the triviality of
> whether to throw versus check for null. Which kind of makes this post
> senseless at some level. The reality is, for resources, either method in an
> application like the "generic" one you describe would not matter because, if
> there is an issue, you are going to get it during development. Once you have
> it working, its a "who cares".[/color]
Absolutely - and using exceptions, you end up with much more readable
code. In particular, you just need:
public static Image RetrieveResourceImage (Assembly assembly,
string resourceName)
{
Assembly entryAssembly = assembly.GetEntryAssembly();
using (Stream stream = entryAssembly.GetManifestResourceStream
(resourceName))
{
return Image.FromStream(stream);
}
}
No need for two extra methods which do nothing but unnecessary error
handling.
(Looking at that code now, it's not right - you're meant to keep the
stream open for the lifetime of the image, which doesn't happen in the
above; it doesn't happen in your code either though.)
[color=blue]
> But, that does not change the fact that one or a thousand, throwing is much
> much slower, and uses more resources than checking for null.[/color]
Actually in this case it's not, because you're not stopping the
exception from being thrown in the first place - you're just catching
it and changing to a different error-handling solution. If higher up
the chain you decide to change back to using an exception, you've
actually just doubled the number of exceptions which need to be
thrown...
Regardless, if you're really worried about the ~0.01ms for the single
exception which is likely to halt processing of that request or
whatever anyway, I think using a platform like .NET is a bad idea
anyway. Do you avoid ever creating objects unless you absolutely have
to as well, whether or not it leads to less readable code?
[color=blue][color=green]
> > When was the last time you actually had code which threw several
> > thousand exceptions (in a relatively short space of time) either in the
> > debugger or out of it? I suggest that if you get into that situation
> > often, you have more drastic worries than waiting for the debugger.[/color]
>
> Uh, today. I ran your sample. And mine a couple of days before that. :)[/color]
Touche.
[color=blue]
> Actually, I don't have that problem, because I use them where I need to, and
> use checks where I need to.[/color]
So you haven't run into it as an actual problem, but you're adding lots
and lots of code doing error checking in order to avoid this supposed
problem?
[color=blue][color=green]
> > And that's the kind of precision I was working at - nearly half a
> > second for the 100,000,000 cycles, which is enough to give an order-of-
> > magnitude figure, which is what we're interested in here. Any test
> > which *actually* relies on timing so small that the high precision
> > timer is required is probably going to be influenced too heavily by
> > JITting etc to be much use.[/color]
>
> You did run your test twice didn't you? So that it had already been JITed.[/color]
JITting happens every time you run the app, not just once (unless you
use Ngen).
[color=blue]
> I don't know where you get 100,000,000 throws = a half a second.[/color]
I never said that I did. I said I got 100,000,000 checks for nullity in
half a second - reread the post.
[color=blue]
> Mine, in release mode was over 1 and 1/2 seconds for 100,000. And
> while my box ain't the latest, its plenty fast. It is a simple
> statement. Exceptions are slower. Use them wisely.[/color]
"Premature optimization is the root of all evil (or at least most of
it) in programming." - Donald Knuth.
I'm throwing exceptions merrily and avoiding lots of return value
checking. I can hand-on-heart say that I've *never* found exceptions to
be a performance problem. It sounds like you haven't except in the very
strange situation you wrote about before. Now, doesn't avoiding
exceptions sound like premature optimisation?
[color=blue][color=green][color=darkred]
> >> None the less, this just ups the factor by which you can save time.[/color]
> >
> > Only if you don't also rerun the exception test - and in release mode
> > this time.[/color]
>
> Release or debug, exceptions are still slower. Dramtically slower.[/color]
Yup, but not nearly as bad as they look in debug. And they're
sufficiently fast that I just don't care, so long as my program doesn't
have the kind of problem that means I'm throwing tens of thousands of
them a minute - in which case I've got far bigger fish to fry.
Suppose my app *were* throwing 10,000 exceptions per minute, and let's
say my computer could only throw 50,000 exceptions per second (instead
of the 89,000 it can actually do.)
That still means that it would only be taking up about 0.3% of the
processor time *even in a situation where I would be very, very
concerned for other reasons*.
When looking for performance optimisations, I look for things which
will gain me an order of magnitude, or at the *very, very* least
increase performance by more than 1% (usually much more).
Out of interest, how many apps which use exceptions freely like I do
really suffer a *significant* performance problem due to it?
[color=blue][color=green]
> > You know exactly what gives you the exception when you look at the
> > stack trace.[/color]
>
> I know exactly what gave me null when I ask for it.[/color]
Only if you either check for null immediately. What if you forget, and
pass the parameter to a method which stashes it for a while, or perhaps
doesn't even throw an exception, but takes a different course?
[color=blue]
> I know exactly what asserted when I asserted it.[/color]
Do you have assertions turned on in the field? If so, that's costing
you performance *when things are working*. The ability to throw
exceptions is basically free when things are working. I'd rather have
code that performs slightly worse in the debugger but slightly better
in the field than vice versa.
[color=blue]
> A stack trace is not something I want to resort to unless there is a
> real problem at hand. When my application throws an exception, I
> don't normally go look at the stack trace. I look at where the
> debugger was when it threw.[/color]
That's because you don't use exceptions as your preferred event
handling mechanism though. I'm quite prepared to see exceptions in the
diagnostic logs for real world apps,
[color=blue][color=green][color=darkred]
> >> I really don't want to spend my life worrying about exceptions and stack
> >> traces over something that I can easily handle another way.[/color]
> >
> > Whereas I *certainly* don't want to spend my life checking return
> > values over something (error handling) that I can easily handle another
> > way - using exceptions.[/color]
>
> To each his own. Such is life.[/color]
I've been having to read a load of C code that deals with errors in
what I view as the old-fashioned way. I then come back to me C# and
Java code and thank goodness for exceptions which can make life sane
again...
[color=blue][color=green]
> > That doesn't prove that exceptions are a bad thing, just that they can
> > be abused like anything else. That story could easily have been the
> > other way round, couldn't it?[/color]
>
> Ah, my point comes through. Use them judiciously I say.[/color]
And I've never said otherwise - but I view your avoidance of exceptions
on performance grounds as unjudicious, if there is such a word. It
seems to be based on a bogey-man which no-one ever really sees - the
app which *does* have performance problems due to over-use of
exceptions.
[color=blue]
> And yes, I am sure you could say it could go the other. That is why I use
> both.
>
> And that is why I recommend the right one for the right use. (But we will
> probably never get consensus on the "right use" or the "right one". :)[/color]
We certainly won't if you keep arguing against their use due to
performance reasons.
--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
