Does try-catch significanlt influences game speed?

Performance Tuning
#21

[quote]Oh, ok. So whenever someone says something blatantly wrong, I’m supposed to ignore it and assume he really means the right thing? Gotcha. =)
[/quote]
Your reply came AFTER Blah^3 clarified his statement about catch by adding:[quote]I meant "everything from the moment of moving out of the non-exception-related code…
[/quote]
It just seemed that you still didn’t have a clear picture of what he was trying to say.

Corrections are always welcome. In this case you seemed to have missed the clarification and focused on the strict interpretation of the bit that was wrong. Yes it should absolutely be clarified that the existence and execution of a catch block is not really the time consuming part of the exception processing, however the time consuming part must happen as part of getting to the execution of a catch block… it’s that distinction that Blah^3 missed in his earlier post and if someone stopped reading there they could easily get the wrong idea.

It was a simple miscommunication. No need to be upset about it.

#22

So to be perfectly honest… I figured this wasn’t worth debating or dwelling on and so, after I had made sure my point was clear, I just stopped reading the trehad.

Sounds like its just as well that I did. shrug

#23

What an “exceptional” idea Jeff! ;D

Kev

#24

That kind of thinking might catch on!

Cas :slight_smile:

#25

I really did try not to throw in another post, but finally I did. :smiley:

#26

And… relax.

Kev

#27

And I have to Object to this kind of… oh nevermind, that didn’t really work.

/me watches another episode of Fullmetal Alchemist

#28

Enough of this! :slight_smile:

Thread.stop();
#29

Warning at line 1: Thread.stop()
This joke has been deprecated.

Cas :slight_smile:

#30

wait, we’re talking about brownies right?

#31

Another variation on Jeff’s “pre-create the Exception” hack is to have your own subclass of Exception and override the method fillInStackTrace to be a no-op. These Exceptions are much quicker to create then, and you can create, throw and catch them as normal, but the create bit is cheaper. Unfortunately, they have no stack trace, so they are a lot less useful :wink:

#32

I think alot of the discussion here has missed the mark quite abit… (it’s a good discussion, though the author might not have gotten the answer he needed…)

To focus on just the thing the original author is asking… his code obviously is not using throwing errors as control flow except for exceptional cases… evident from System.exit()…

So he’s asking if he gets much penalty for just using the try catch block… for an exception that hardly ever occurs…

And this is for code executed 50 times a second… I’d say that in this specific instance, that there is no chance in the world he’d see any kind of performance difference by removing the try catch block (a catch that never occurs)… (on any kind of normal pc that is… maybe some super slow mobile… but I’d even doubt that)…

This is the wrong place to look for optimization… try optimizing things that occur hundreds or thousands of times per frame… not things that occur just once(!) per frame!

An important lesson to learn for new programmers is where to look for optimizations… or you’ll spend alot of time optimizing stuff that wont make any difference anyway. Of course you have to know ways to optimize code… but when you do… look for places in the code where the optimization will matter! (such as very tight loops… 50 times a second isn’t a tight loop…)