I would like to know what is the real different between blueprint and c++ in performance, not estimated values, real values, thanks .
Do a search on Google before making threads next time.
I did, and it still doesn’t answer precisely, after i posted it i found that a developer or ue4 said it is about 10x faster, but i already posted it, so i would like to know what others have to say, and it will also make the search of other users easier .
1 Like
Have a look at this post from Billy:
As I posted in another thread here, normally it should be okay to run a scripting VM (like Blueprint) because most games are bottlenecked by the GPU rather than the CPU from what I’ve seen on PC, etc.
So, I am not sure what your objective is in asking this question. Also, as a rule of thumb, optimize when you need to (not before). I wouldn’t worry about Blueprints over much unless it pops up on the profiles. Then you gradually move those expensive routines into C++. I personally haven’t had any issues with blueprints but my project is in the infant stages
Blueprints do not perform particularly well compared to C++. Still, most people share the opinion that for the most part “slower than C++” and “too slow to be used” are different things. Obviously, people don’t mind using blueprints and Epic supports them. I don’t know how blueprints compare to UnrealScript or C#, but I think they don’t have a reason to be a thousand times faster…
Some of you will dismiss me after saying that I don’t like coding in C++ and think that it feels ancient. However, that’s the primary reason I would like to have a more modern alternative. I am sure there are many people who feel the same way, especially since UE4 tries to step into indie world.
Would it be impossible to allow another language to be used the way blueprints are used? Can’t a more modern language run on top and call C++ functions for the heavy lifting?
There are the hardcore coders that like C++, and there are the people who faint when they look at any code (hence blueprints). But there are also the people in the middle who can code, but don’t want to go back in time and learn C++ - a language that takes a significantly greater effort to learn properly. The thought of learning C++ certainly does not excite me, it gives me feelings that are very contrasting to game development, which is inspiring and creative. If a game is created by 1-3 people, chances are they have to work on all kinds of things (game and level design, modelling, textures, game logic, promotion etc) So the team probably doesn’t include a hardcore programmer.
On the other side of things, blueprints feel less powerful and not suited for complicated logic. Duplicating nodes, dragging lines and ending up in something that I need a 27 inch monitor to be able to see even partially (and then pan horizontally and vertically) makes me feel inefficient, having in mind my coding skills. Something that can be coded in 100 lines (that would look much cleaner and maintainable, especially when the algorithm is complex) shouldn’t be done in blueprints that if printed would take an A1 sheet.
So there is a big gray area between blueprints and C++ that I fall in, and for me this is one of the biggest disadvantages of Unreal Engine 4.
2 Likes
Yeah I feel the same way. I can code, but I don’t want to learn c++ because it really feels and looks like a step back. So I am using blueprints instead, which is basically just coding, but sometimes just a lot more inefficient than writing lines of code.
I’m still new to UE4 but when I look at Blueprint code, what is produced reads the same as their assisted C++. So a visual programmer in Unreal is an assisted C++ game programmer, as far as I can see.
The downside with visual scripting is you can’t do anything complex, without making it difficult or impossible for others to read and maintain. Another thing, you can’t do a diff and see what functionality has changed and you can’t use your script in any other engine or code base. There is also the problem where it obscures how classes are interrelated. And if Unreal decides to discontinue BP like they did with UnrealScript, you will have to start again. So I think getting heavily into BP and ignoring C++, will ultimately stunt your growth as a programmer.
I personally think scripting is for making games - do all the heavy lifting in C++ and have a very simple network of game logic. That means no while loops, just a sequence of functions in response to game events. Not only can you make games quickly using that method, players with no programming experience can also mod it.
However I have come around to the idea that all interfaces should be scripted.
Edit:
To answer the OP, according to this BP is around 10x slower than C++, but that is assumed with script.
If I create the main character in C++ and make it into a Blueprint so I can tweak some values (only changing Default Class values), then I manually place that blueprint into the world (drag and drop from content browser). Am I losing all the speed advantages of coding in C++ in the first place?
No you will not as variables are set at initalization time.
To avoid performance issues just minimize bp to c++ calls during tick events…
I get your point, but this seemed a bit harsh to me.
I agree partly with this. I am not a programmer (at least not a skilled one), but having used Blueprint and then trying to get into C++ for UE4 made me understand code a lot more. However, Blueprint can do a lot more complex things than traditional visual scripting, even while remaining readable for others. I also thought that it was somehow possible to compare two version and see what has changed. On another note, UE4 uses C++ very differently. The core of the engine is written in pure C++, but the more you move up, the more has been simplified. Basically, the code you write when developing a game does not have to be pure C++, Epic has created a lot of macro’s and classes that would make coding easier, which also means you cannot reuse code in another engine.
But, I do not think Epic will discontinue BP anytime in the foreseeable future. They highly advocated BP as an alternative to coding, and also make extensive use of it. It is a core feature of the engine, and considering its predecessor UnrealScript having been around from 1998 all the way to 2013 with the last UDK version, I think it’s here to stay. If they do replace it, than I think we would have enough resources to switch over.
On yet another note, I think C++ is not ancient. It is still widely used for almost any program (at least those that run on Windows). For me at least, it’s not a step back from C#, but a huge step up. I will likely never be able to program complex software, but I am not scared of C++, especially not in Unreal Engine.
1 Like
Unreal Engine C++ is not that difficult. Macros do help a lot but you need to get used to regarding how stuffs are done…
That being said, you should have created a new topic rather than necroing this.
Of course you can’t just copy and paste it. You will have to remove some things and add others, but the logic inside the functions remains the same. As an example, I had to do a conversion to use my code base with the the last engine I was with and unless Unreal has better functionality, I will convert the same code base for Unreal.
May not be soon, but it will happen eventually. It depends on whether the workflow is judged superior by the masses or not. For instance, friends are telling me another engine is easier to get started with, however I’m pushing through the pain barrier, because the rate this engine is advancing at is incredible. However if Unreal wasn’t the technology leader that it is, I would certainly be trying the engine that is easier to learn. If enough people did the same, you would find Epic changing its tune very quickly.
C++ is kind of like QWERTY keyboards. 
It was first to become popular in game engines, so it will always be the standard. Also its much faster than anything else and a game engine developed in a slower language, is just not going to be competitive. Of course no need to say that here of all places. lol
Edit:
But yeah each to his own. I wouldn’t think about BP at all if there was a C++ section in the marketplace. Anyone know what is up with that? Is a C++ section coming or not?
Does anyone know if they’re working or planning on improving blueprint performance in future versions? Or if it is somehow fundamentally impossible for some reason?
BP is fine, they are not meant to be total replacement for C++ rather they compliment it where your C++ programmer doesn’t want to get bogged down by designers (designers can craft their own BP).
I think BP being very high-level and C++ being low level is just nice blend. If there are scripts where they are quite fast, but the syntax is close to C++ (which is still beyond non-programmer) then it is quite impractical. BP caters to non-programmers in the way it is not possible at all via script, and C++ programmers can continue programming in their own world… lol.
Benchmark UE4 Performance: C++ vs Blueprint
Sorry for bumping this post, however it is an important question for many of us. As many have stated, I was also expecting blueprint to be much slower than c++, but to make a long story short, I had a 100% Blueprint project, I decided to rewrite it completely in c++, using only Blueprint as a commodity for appearance / positioning / simple interactions. I had a performance boost, but nothing spectacular, even though I optimized my c++ code (I am a computational scientist with 15 years experience).
Since I had a mixed feeling and I was still unsure of the performance loss due to BP, I finally decided to create a new and very small project: 1 pawn in c++, the exact same in BP, each pawn with a simple method to move the pawn (interesting for AI simulations).
Here are the results, each value has been computed at least 3 times to lower artifacts:
For 400 actors:
- in Editor: 79 fps (c version) vs 69 fps (blueprint version)
- Package (ship): 156 fps (c version) vs 157 fps (blueprint version) (no simulation: 180 fps)
For 800 actors:
- in Editor: 49 fps (c version) vs 43 fps (blueprint version)
- Package (ship): 80 fps (c version) vs 78 fps (blueprint version) (no simulation: 115 fps)
For 1200 actors:
- in Editor: 36 fps (c version) vs 31 fps (blueprint version)
- Package (ship): 65 fps (c version) vs 60 fps (blueprint version) (no simulation: 95 fps)
For 1200 actors (no mesh):
- in Editor: 59 fps (c version) vs 47 fps (blueprint version)
- Package (ship): 160 fps (c version) vs 132 fps (blueprint version) (no simulation: capped value at 200 fps)
For 2400 actors (no mesh):
- in Editor: 33 fps (c version) vs 24 fps (blueprint version)
- Package (ship): 71 fps (c version) vs 60 fps (blueprint version) (no simulation: 95 fps)
Notes:
- Tests realized on UE 4.12.5
- I put t.maxFPS to 200 fps for those tests, so 156 fps is 156 fps, not a capped value
- XXX actors: means XXX actors are simulated, but the scene contains twice that number (C++ actor + BP actor)
- Checking Stat Unit, the Game Thread was always the limiting factor, but the more actors the scene contains, the more it bias the comparison C++ vs BP
- Hence, above 1200 actors, I remove the cube mesh of each actor, then only the Game Thread was limiting.
- Packaging in Development rather than Shipping mode influences those results: with 800 actors, I was roughly at 69 fps for both c++ and bp versions instead of the 80/78 fps in Shipping mode.
Conclusions:
- ok package versions much faster, logical since no overhead from editor
- inside the editor, yes blueprint is always slower than C++ (10-40%)
- inside the editor, the more actors you have, the more differences you will see between BP and C++ (at 2400 actors: BP 37,5% slower than C++, at 1200 actors: 25,5%)
- in packaged versions, the differences between BP and C++ versions are much smaller: 8% for 1200 actors with mesh. But at 1200 actors with mesh, the Draw Thread is influencing the fps.
- to remove the impact of Draw Thread, I removed the mesh of those 1200 actors. Stat unit & the 200 fps count confirmed that only the Game Thread is driving the fps. When starting the simulation, the frame rates drops from 200+ to 160 fps for the C++ version and 132 fps for the BP version. We can consider this result as a 21% brute gain performance of using C++ over BP.
For completeness, I added several computations during the simulation (cos, sin, pow, random, etc).
- At 1200 actors with mesh the limiting factor is now again the Game Thread (due to added computations)
- As always in the editor, BP is much slower than C++. Before adding these computations, BP were 16% slower, now they are 28% slower with the added computations
- In the packaged (ship) version however, the result is consistent with the Conclusion 5). With those added computations, the C++ version runs at 49 fps while the BP version runs at 40 fps. In other terms, C++ shows a 22% brute gain performance over BP
**Global Conclusions: ** (only concerns packaged version as editor doesn’t matter for final products)
- Yes, C++ is faster than BP
- BUT C++ is not at all 10 times faster than BP, even for pure computations. If anyone as a test case showing this 10 times faster I would be very interested to see that
- In my tests, the gain of using C++ for specific computations was roughly 20%. I don’t expect this gain to be more than 30%, even for stronger computations
- BP is surprisingly very fast, I’ve read somewhere the development team is working on translating BP in C++, perhaps is it already partially done ? Anyhow BP is just an interface to actually call the C++ codes of UE4 platform.
- I would advise to use C++ only when tremendous calculations are involved as the performance gain is not as important as one would expect / hope OR when you need more flexibility than Blueprint for your project architecture. Note BP is still very flexible.
For me, UE4 Blueprints are a true technical success.
In the end, it’s your optimized algorithm that makes a true difference.
Cheers,
8 Likes
Dude that post was baller. Thanks for taking the time to test all that, and more importantly, letting us know the findings.
Very cool! Love mathematical posts like these! Thanks a lot 
Many (speed critical) work is done by the engine already anyway. If you do dumb stuff you could kill performance even with C++. Blueprints are designed in a very object oriented and event based way which is good. Even development speed especially at early stages is very good as you have to do less steps (e.g. no need to prepare stuff in headers first) and to get your items into the world and less wait-time to simulate your game (no compile). However at bigger projects I miss my “grep this | grep that” or more advanced search functions to dig quickly through my sources as usuall with C++ and if some unexpected is happening (like some BP nodes that disconnect the wires after you start your editor next time for unknown reason) it could be a pain or almost impossible to debug.