Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 13 Next capture
2021 2022 2023
1 capture
13 Jun 22 - 13 Jun 22
sparklines
Close Help
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
1
Question by Screenhog · Sep 05, 2012 at 05:50 PM · performancespeedmathoperatorcomparison

< cheaper than <= ?

I had heard a long time ago that using < was computationally faster than <=. The reasoning was that <= was just a shorthand for < and =, which meant that the program would have to perform two comparison checks. Can anyone confirm or deny this?

Comment
Add comment
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

2 Replies

· Add your reply
  • Sort: 
avatar image
3
Best Answer

Answer by Eric5h5 · Sep 05, 2012 at 10:30 PM

<= is not any faster or slower than <. You can confirm this by running a simple benchmark. See the question about this on Stack Overflow.

Comment
Add comment · Show 1 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Screenhog · Sep 05, 2012 at 10:34 PM 0
Share

Thank you Eric. I'd hoped you'd have a final answer on this.

avatar image
3

Answer by Owen-Reynolds · Sep 05, 2012 at 07:32 PM

Stuff like `<` vs '`<=` is pretty far down on the list of things to worry about. The usual rules, in order, are:

o Don't optimize early. Always choose to write a readable program over a "fast" one. There's a good chance things will change and your optimized code section will be a pain to update.

o Don't bother with infrequent code sections. Monsters only die once, so no point making "die" run faster. Focus on things that happen every frame.

o Look at the big picture. Does target acquisition need to run every frame? Does every monster have a local copy of common data that could be stored in just one place (bigger programs can't fit into L1 cache, so run slower.) Shouldn't that giant nested-if/switch be turned into an array lookup?

o Don't assume you're smarter than the compiler. It's likely that `if(a<=b) do C; else do D` will get flipped around during compile to `if(a>b) do D; else do C`.

Comment
Add comment · Show 4 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Screenhog · Sep 05, 2012 at 08:33 PM 0
Share

That's good advice. However, I was mostly just asking out of curiosity. I wouldn't be a bit surprised if a program could do a million >= operations in a second, I just wondered if > was faster.

Plus, thinking in terms of > ins$$anonymous$$d of >= is an easy enough way to optimize that it wouldn't turn code unreadable, so knowing the rule had some benefit in my $$anonymous$$d.

avatar image Eric5h5 · Sep 05, 2012 at 10:33 PM 0
Share

Always write for readability first. The example in $$anonymous$$ike's answer of using (a < b+1) rather than (a <= b) is exactly what you should not do. Especially since neither is actually any faster than the other.

avatar image Owen-Reynolds · Sep 05, 2012 at 10:56 PM 1
Share

Screenhog: there's usually an "obvious" operator for readability. For example, `if(x<200)` looks like an "off left-edge" check (200 is the smallest, true is bad,) while `if(x<=200)` looks more like a "not past right-edge check" where true is good.

avatar image Fattie · Sep 06, 2012 at 08:54 AM 0
Share

Everything Owen says here is deeply, deeply important. It is incredibly valuable advice.

In particular, points 4, 3, 2 and 1 are extremely critical.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this Question

Answers Answers and Comments

11 People are following this question.

avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

Related Questions

Use the word "new" or not (Performance) 3 Answers

Wild fluctuations in performance when built into an exe... 1 Answer

What's killing my rendering performance? (pic included) 1 Answer

Rotate an object in a specific time 0 Answers

Ternary operator fails, but verbose comparison doesnt? 1 Answer


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges