Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Does try-catch significanlt influences game speed?  (Read 5844 times)
0 Members and 1 Guest are viewing this topic.
Offline gcsaba2

Junior Member




Hello world


« Posted 2005-04-24 21:12:47 »

I was wondering if the try-catch block significantly influences the game speed. Let's say I have a map class that draws something each frame. If something goes wrong, it throws a MapException. Because of this, in my game's rendering method I have something like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
try
{
   Map.render();
}
catch (MapException mex)
{
   System.err.println("Error with drawing the map");
   System.exit(1);
}

Now this part of code is called probably about 50 times per second, so I was wondering if it's severly influencing the game speed. Throwing and catching errors is not that important anyway cause once the game is built up a map won't be able to throw any exceptions cause there will be none, but if it doesn't influence the game speed I might leave it there just in case the user's computer explodes Grin

Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #1 - Posted 2005-04-24 21:53:32 »

Catching exceptions in pretty expensive.  As a general rule, you wouldn't want one in a rendering loop.   For developing it won't hurt though.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2005-04-24 22:57:51 »

try costs effectively nothing, catch costs 100 x a normal method call (yes, 2 orders of magnitude).

So, use exceptions for exceptional situations, NEVER for control flow...

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cknoll

Junior Member




Flame On!


« Reply #3 - Posted 2005-04-25 13:00:22 »

Quote
try costs effectively nothing, catch costs 100 x a normal method call


Do you think you could write something to demonstrate this figure without being classifed as a 'microbenchmark'?

-Chris
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2005-04-25 18:43:14 »

It's a Known Fact (tm). It used to be more, IIRC, (although not sure).

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #5 - Posted 2005-04-26 03:36:04 »

"Known Facts" (TM)  are always the most suspect.  Wink

In fact, catch is not terribly expensive at all. What IS expensive is creating the stack trace when you create the exception.

A questionable but sometiems useful practic is to pre-generate the exception and save it.

If you do this then each throw is not very expensive at all.

The questionable part is that what youa re telling the code catchign the expcetion is nto the actual state at excpetion time but an analgous state you manufactured earlier.   The last line or so of the trace  will be wrong.  How wrong and how much of it is wrong depends  on how clsoe to the actual throwe statement you did the earlier "new".

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2005-04-26 04:28:11 »

Biggest issue here though is this....

Yo ushould NEVER be using try/catch as aprt of your normal execution logic.

Exceptions are for EXCEPTIONAL conditions, thats why they are called exceptions.  The system is going to assum that if you are throwing an exception you are outside of normal opration and thus its really free to take as long as it wants to.

DON'T use exceptions except where a genuine unexpected condition has ocurred.  Thats what they are for.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2005-04-26 07:05:24 »

Quote
"Known Facts" (TM)  are always the most suspect.  Wink


Yep, which is why I flagged it like that Tongue so that people would know what baggage the statement came with. Just recently I saw some detailed figures for the catch penalty, compared across gcc/msvc/java in lots of different configurations, and it's still clearly "a lot".

You cannot go around using exceptions as part of your normal control flow if you care at all about performance. It's not something that is WORTH the JVM vendor optimizing (it serves no purpose; people who need faster catch are abusing it), so ... don't even try to use it because likely it'll never get much faster.

Quote

In fact, catch is not terribly expensive at all. What IS expensive is creating the stack trace when you create the exception.


Of course. When I said "catch" I meant "the execution of code that is done to implement the catchng", which necessarily includes capturing the stack trace, and seemed the most obvious interpretation given the context.

malloc will be first against the wall when the revolution comes...
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #8 - Posted 2005-04-26 07:44:47 »

Throwing and catching exceptions within your constructors or deinitialisations methods is fine.

Outside of constructors/deinitialisations methods within your game, you should avoid throwing exceptions alltogether because like the people above have said it will drag down your performance.

This sums it up quickly. Smiley

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #9 - Posted 2005-04-26 10:03:38 »

Nah, using exceptions outside of constructors is fine as long as you use them appropriately. It will not affect performance.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #10 - Posted 2005-04-26 15:35:46 »

Quote


Of course. When I said "catch" I meant "the execution of code that is done to implement the catchng", which necessarily includes capturing the stack trace, and seemed the most obvious interpretation given the context.


Except it doesnt.  Read the end of that post.

In any event, its not part of a catch at all.  It IS part of a typical throw but, as I said, thats avoidable if you really need to avoid it.

Precision of thought is important in performance tuning as it leads to precision of action.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2005-04-26 16:40:48 »

Quote


Except it doesnt.  Read the end of that post.


Sigh. I understand perfectly what you're saying, but you're not realizing the intent I was explicit about conveying. Shrug. If you're going to highlight the value of precision, I'm going to highlight the value of trying to understand people rather than just reading their words as gospel Tongue.

Quote

In any event, its not part of a catch at all.  It IS part of a typical throw but, as I said, thats avoidable if you really need to avoid it.


To say what I said before, in a different way: I meant "everything from the moment of moving out of the non-exception-related code and into the exception-related code up until the point you move back into non-exception-related code" but was glossing over the details for the reasons I described - it just doesn't matter IMHO.

By taking my words too pedantically and not paying attention to the concept you mistook what I said Tongue Grin

malloc will be first against the wall when the revolution comes...
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #12 - Posted 2005-04-27 12:55:35 »

I don't think you're understanding what he's saying at all.


1  
for (int i=0; i<100; i++) { try { foo(); } catch (RuntimeException e) { bar(); } }

You seem to think that that code is slow because of the catch in there.

It isn't.
In fact, it's not much slower than this:
1  
for (int i=0; i<100; i++) { foo(); }

Sure, it's slower, but certainly not by orders of magnitude.

The thing that makes an exception slow is the creation of the exception, not the catching.

To make it really clear, this is horribly slow:
1  
for (int i=0; i<100; i++) lastException = new NullPointerException("omg!");

Play Minecraft!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2005-04-27 14:14:32 »

Quote
I don't think you're understanding what he's saying at all.


I think it is you who is misunderstanding now.

I think blah^3 is saying that the code needed to actually process an exception, is slow.  This code by necessity includes creating an exception object.  Even if you pre-create it, we are talking about the cost of creating the object, not when you do it.

Exception processing as it is discussed above includes creating the exception, the 'throw', all the stack unwinding, and the 'catch'

You can optimize the really expensive part of that by pre-creating the exception objects as Jeff stated.  That will have side-effects that are also stated in Jeff's post.  If exceptions are used properly (only in exceptional circumstances) I can't think of a good case for doing that optimization.

In any case, as you point out, the safety net of the try-catch block itself is not a significant factor.

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #14 - Posted 2005-04-27 14:54:33 »

Oh, ok. So whenever someone says something blatantly wrong, I'm supposed to ignore it and assume he really means the right thing? Gotcha. =)

Play Minecraft!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2005-04-27 18:21:27 »

Quote

I think blah^3 is saying that the code needed to actually process an exception, is slow.  This code by necessity includes creating an exception object.  Even if you pre-create it, we are talking about the cost of creating the object, not when you do it.


Yes. Thank you. Without putting too fine a point on it, I'm somewhat suprised by the narrowness of perspective here: that people can't read "the code that does X" to mean "the compiled instructions" that "make X happen" rather than "the lines of source I write in a sequential block" that "do a very precise part of a bigger process, and don't make sense on their own conceptually but are just one small aspect of the concept".

When talking about performance, what I care about is *what actually happens*. When comparing inserted code, what I care about is *what the difference in execution paths is, and what one does extra that the other does not do*. I say this only to try and clarify my perspective here. Maybe it's not the best way to look at things (? Suggestions gratefully received...) but to date it's served me extremely well in writing high-performance code, typically outdoing the best that anyone else had come up with in the same areas.

Quote

You can optimize the really expensive part of that by pre-creating the exception objects as Jeff stated.


In the midst of all this, I forgot to say this, but I think that's a very neat trick. Suicidally hacky, and something to avoid like the plague, but still a neat trick Grin. I can see myself perhaps using it in the future, as one of my toolbox of "vile horrible things you very occasionally have to do in java when you're writing very powerful code and run up against the barriers of java forcing you to do things because it errs on the side of caution *even when you can statically determine such erring is useless*".

malloc will be first against the wall when the revolution comes...
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #16 - Posted 2005-04-28 07:15:52 »

But you were wrong!

You said that catching an exception was slow. It isn't. Throwing an exception isn't slow either.
If people listened to what you said, they'd avoid doing things like catching an exception, processing, and rethrowing the same exception.

That's virtually free compared to the cost of creating a new exception, but from your explanation ("a catch is orders of magnitude slower than a normal method call"), you'd think it was slow.


Bah, fine. I'll start saying things like "you drink coffee with a fork", then say that "of course everyone realizes that you have a CAKE with your coffee! What else would you use the fork for?"

Play Minecraft!
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #17 - Posted 2005-04-28 08:20:25 »

Judging by you two arguing, can I conclude that it's the creation of the exception which is the slowest part?

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline tusaki

Junior Member


Medals: 1


In a mad world only the mad are sane.


« Reply #18 - Posted 2005-04-28 12:04:05 »

Basically, this is ok:

1  
2  
3  
4  
5  
      try {
            render();
      } catch(HorribleSystemException e) {
            showGameUnableToContinueDueToSystemFaultDialog(e);
      }


and this is not:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
      try {
            getPacmanMovement();
      } catch(PacManMoveRightException e) {
            moveRight();
      } catch(PacManMoveLeftException e) {
            moveLeft();
      } catch(PacManMoveUpException e) {
            moveUp();
      } catch(PacManMoveDownException e) {
            moveDown();
      }


Regards,
- Vincent
Offline cliffc

Junior Newbie




Chief JVM Architect @ Azul Systems


« Reply #19 - Posted 2005-04-28 14:39:06 »


Quote
Judging by you two arguing, can I conclude that it's the creation of the exception which is the slowest part?


Yup.

And also using pre-cooked exceptions as control flow is much slower than any other reasonable solution (such as checking return values for a special error code).  Under very restricted circumstances the server compiler will manage to make such control flow close in speed to the obvious test&branch, normally you should expect that throwing & catching a pre-cooked exception to be at least 10x slower than simply testing a return condition.

Declaring a try block and not throwing is free (nearly) so it doesn't cost to be robust and catch exceptions that are rarely thrown.

Cliff Click, PhD - org dot acm at cliffc
High Performance Java VM Design and Implementation
Azul Systems
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #20 - Posted 2005-04-28 18:35:05 »

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. =)


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...


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.

Offline Jeff

JGO Coder




Got any cats?


« Reply #21 - Posted 2005-04-29 02:47:47 »

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**

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #22 - Posted 2005-04-29 05:44:49 »

What an "exceptional" idea Jeff!   Grin

Kev

Online princec

JGO Kernel


Medals: 365
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2005-04-29 06:55:54 »

That kind of thinking might catch on!

Cas Smiley

Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #24 - Posted 2005-04-29 09:28:58 »

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

Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #25 - Posted 2005-04-29 10:27:01 »

And... relax.

Kev

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #26 - Posted 2005-05-02 05:19:52 »

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

/me watches another episode of Fullmetal Alchemist

Play Minecraft!
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #27 - Posted 2005-05-02 13:57:00 »

Enough of this! Smiley

1  
Thread.stop();

Online princec

JGO Kernel


Medals: 365
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #28 - Posted 2005-05-02 14:04:27 »

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

Cas Smiley

Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #29 - Posted 2005-05-04 01:57:52 »

wait, we're talking about brownies right?

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (15 views)
2014-08-28 18:26:30

CopyableCougar4 (25 views)
2014-08-22 19:31:30

atombrot (38 views)
2014-08-19 09:29:53

Tekkerue (33 views)
2014-08-16 06:45:27

Tekkerue (32 views)
2014-08-16 06:22:17

Tekkerue (20 views)
2014-08-16 06:20:21

Tekkerue (29 views)
2014-08-16 06:12:11

Rayexar (66 views)
2014-08-11 02:49:23

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!