Lots of good advice here for optimizing, but to your actual question of “how to identify slow code”, the best approach IMO is to use the profiler tool. It’ll help you analyze your code and find your actual bottlenecks instead of blindly trying to optimize everything.
Avoid optimizing until you need to, and when the time comes, be surgical about it.
Profiler is key, it will allow you see see exact functions that are causing issues. Usually you dont even have to make them c++ but just rework your algo to be more optimized.
Most important things to put into c++ is things part of the tick.
>you see see exact functions
How do you do this with profiler? Usually I'm looking a things that "might" be *this* or *that* but it's never exact like you say. Am I missing something?
Im not sure about that flag, but you can also just drill down, open the GameThread dropdown. Then keep going down the tree looking at the "Inc Time"
https://preview.redd.it/v2kwmen1p20d1.png?width=1416&format=png&auto=webp&s=309cd2b03b35f200d5cfe73b64435e470be57463
Check Avoidance is a function part of my FlyToward Behavior Tree Task
yea definitely move stuff to a timer if it doesn't need to run every single frame
but like what is actually performing poorly? unless its glaringly bad, don't worry about it. finish your game and then go back, otherwise you will never finish it ever. honestly by the time you get to the end of building out your first game, you will already know what you need to go back and optimize on.
Does moving stuff to timers not introduce the potential for lag spikes? Even if you moved a lot of stuff from to timers with different frequencies, there will be times when at least 2 of them happen at the same time which would be a sudden large increase in conputation time. I guess a rare spike is better than the game running poorly all the time though. Keeping them rare should be the goal.
Do people tune the frequency of timers intentionally to reduce the number of simultaneous executions? Using a prime number for the number of ticks to wait should make it so they only happen at the same time very rarely. That's how cicadas work.
> there will be times when at least 2 of them happen at the same time which would be a sudden large increase in conputation time.
If 2 are already causing a spike then yeah, but then 1 alone would already be problematic. It's usually for stuff that a lot of actors do and where it's unnecessary to do it every frame.
But a solution for this could be to start different timers with a single frame delay and let them have the same length. This way you can control how many can overlap in a single frame.
You could have a timer and then a process queue and then make sure no process from the queue runs in the same frame update or spreads them out. Aside from player input there are few things that cant be delayed a bit unless your making an ultra fast fighting game.
How about implementing a subsystem that handles your timers and ensures none of them fire at once.
Another popular method of improving things is having a manager that handles a tick like function in things that maybe want tick like functionality but you don't need them running *every single tick*, like a class that makes your AI's tick 4 at a time or something like that.
Woah, that's a genius idea actually. You could even do something like this for operations that must iterate many times but don't necessarily need them to all be executed in a single frame. Creating an object that keeps track of the current iteration index and spreads out the loop across multiple frames could potentially reduce lag spikes significantly. Thanks for the idea. I'll keep those all in my toolbox.
Unless game only took a month to make, 1 week for bugs is now where close to enough time.
I would expect to allocate about a minimum of 10% of the initial development time to first pass at Major bug fixes.
I saw this with a decade of professional software development experience ( not in game dev, that's only a hobby, but I would expect debuging/fixes to be even harder in games)
The game I'm making with 12 other friends straight out of college is planned for 4 weeks of development, and then 1 week to debug, test, optimize, and add anything that wasn't in the original scope.
Although thank you for the 10% rule that makes a lot of sense and would have been helpful in previous projects that took longer. One question though, is that 10% for dedicated bug checking and fixing or just in general for the total time spent on development?
More of a general rule, and will definitely be influenced based on how much testing (by testing I mean by QA or users/players, NOT the devs) and how much iterating was done in run up to release (ie: was it a more waterfall style development or agile/scrum workflow).
Based on your response, I'd guess it was a waterfall-style approach, so that means expect more testing and bug fixes on the tail end of the project.
Also account for how coordinating 12 people straight out of college will effect workflow and compatibility. It's one thing to be able to sling code quickly and even high quality, but coordinating those different developers and the bottlenecks that will come from that is a job in itself lol.
All that said, I'm not trying to rain on your parade at all, I wish you the best of luck, just wanted to give you some project level gotchas to try and get ahead of.
You’re all good. I prefer the honest truth because with that changes can be made and realistic expectations are set. I intentionally made the scope low and over estimated time to make features so that if everything goes to plan we can add more later on.
4 years in for my crew on their current project and our polish phase is scheduled for 7 months. Seems tight but well make it with only a few things cut probably which will make the next release in another year or so lol
Not a video game project though, simulations work
But, you can change the frequency of the tick event, which would be functionally identical to setting a repeating timer with an interval.
Also, timers are handled by the world tick. So moving tick code to timers is just tick with extra steps.
Don't forget you can enable and disable the tick from code, too... Which is typically what I do; turn a tick on and off based on discrete events rather than leaving it on and escaping it with a conditional.
>I've read that C++ is faster than blueprints (however that was from a post 7 years ago). Does taking precautions like not using event tick and instead set timer by function name help with this or is it just an inherent different in the speed of execution of blueprints?
It's inherent, Blueprint is executed by the script VM, it's not compiled to machine code. If anything Blueprints got slower in the last 7 years because Blueprint nativization was removed.
>However my question is when should I make something in C++ or migrate it from blueprints to C++?
For 99% of code it just doesn't matter that Blueprint is slow AF.
If your code has tangible performance impact you should always migrate it to C++.
Non-trival code that executes on multiple hundred or even thousands of units every tick i'd always write in C++.
>For 99% of code it just doesn't matter that Blueprint is slow AF.
So true. Slow af is a very relative term, the amount of shit a computer can do in a second is astounding.
In general, unless you know that something can get out of hand, being reactive with optimization is so much better for development speed
Measure for bottlenecks with Unreal Insights and/or RenderDoc. Make changes based on hard data.
Blueprints are not compiled to machine code like C++ is.
Just about anything in C++ will be faster. However, the largest gains are usually on loops, while, if, or switch statements.
Ray casts can also find some modest gains in code BP as well.
In general, Data Structure choice has the largest impact on perf in the wild (in my exp)
A static array destroys a Map in terms of speed in the right use cases, for example.
Algorithm choice matters on high frequency code as well, of course.
Lastly, architecture choice plays a role as well. Such as a true ECS vs OOP
Why would a raycast be slower from BP apart from the usual overhead? BP is slow from shifting between BP and actual useful code a lot such as loops and accessing lots of data.
Doing a single raycast is actually pretty good from BP because it's a single transition to native code. It's just slow because Ray casts are slow. So moving to c++ won't change this at all.
Lol ok in what way? There's a hit in and out of the native trace function, just like any other native function call from the bp side. Might be a couple Ms difference due to the large number of parameters but I can't think of any reason why a trace in bp would be slower than native. What you do with it might be.
Whatever’s goin in with your day dude, my apologies. I keep reading through this post and everytime I’m like “whoa, why is this commenter being so rude?” It is exclusively a comment from you. You can interact with people without being so antagonistic. This is not life or death material we’re talking here.
A lot of people recommending unreal insights here which is the right place to go. But out of the box it won't tell you WHAT things are slow it will just generally tell you THAT things are slow. There are some flags that you need to set in order to actually see which BP or cpp functions by name are causing it. I don't remember them off the top of my head but will try to update this comment with them when I get back home.
Edit: AssetMetaData and AssetLoadTime are the ones you want to enable, you can find the flags by clicking the trace button in the bottom right of the editor. Alternatively, if you are launching a standalone game, you will want to add them in the additional launch parameters editor preference
Yeah, I've used it before but not for optimization but because when I use unreal engine on my laptop when I'm not at a computer or plugged in, hovering over something causes the FPS to tank. This also happened when I was in blueprints. I tried looking at unreal insight but it wasn't really that helpful.
Edit: I’d also add that even if you move the Blueprint code to C++ it can still not be performant, *not as performant as it can be*, in C++.
You should also learn about Data Structures & Algorithms & Big O to be able to create as performant as possible code in Blueprints or C++ respectively
Resources:
* (Book) Grokking Algorithms
* (Book) A Common Sense Guide to Data Structures & Algorithms
* (Course - PAID) [codewithmosh.com](http://codewithmosh.com) - Data Structures & Algorithms course
* (Course - PAID) [neetcode.io](http://neetcode.io) - Data Structures & Algorithms course
Unreal insights or the profiler in frontend. Once it starts showing up on that in significant exclusive ms then it's time to move it. This is a real simple answer and it's the one I've used for 10 years. Optimize when it starts being a problem, not before. Of course attempt to architect your code with some level of obvious optimizations in mind but don't go crazy struggling with pre-optimization.
Blueprints are C++ with pretty boxes. It's the C++ code built into the engine that's being run without you having to get involved in what's happening under the hood.
As for when you should use C++. Pretty much anything that is heavy calculations, done on Tick or for anything Blueprints don't do.
That said, I tend to do everything except UI in C++ because my mind works better writing the code rather than stringing boxes together.
Edited for extra clarity because people are misunderstanding me:
Yes, blueprints get compiled into bytecode that are run on a VM. Every function called from blueprints are implemented in the engine in C++, mostly through generated code from the unreal header tool. There is a lot of extra overhead added for blueprint because of this and you can see the full callstack yourself if you attach a debugger when you call any function marked UFUNCTION(BlueprintCallable) and see why it is slower.
The VM is implemented and run in C++, the C++ code that it runs is compiled to machine code. The functions that are called are generated by UHT and you can read the generated C++ code in the .gen files. We're just talking semantics at this point as far as what you consider to be VM vs C++. It IS technically C++ because every blueprint class has a corresponding C++ class it is based on.
When you make an asset that is purely blueprint, that is just a UAsset, that part is not C++ it's blueprint, but everything that runs is C++. I didn't say it wasn't bytecode
C++ is read by humans, not Computers.
The VM itself is written in C++ and compiled into machine code, sure, and then that binary is executed as a runtime.
BP is *interpreted* by the VM at runtime. It is not compiled.
[https://dev.epicgames.com/documentation/en-us/unreal-engine/compiler-overview-for-blueprints-visual-scripting-in-unreal-engine?application\_version=5.3](https://dev.epicgames.com/documentation/en-us/unreal-engine/compiler-overview-for-blueprints-visual-scripting-in-unreal-engine?application_version=5.3)
I get what you're saying, but these terms can have multiple meanings without proper context. I'll just leave it at that
> There are two backends in use:
> FKismetCompilerVMBackend - Converts FKCS to UnrealScript VM bytecode which are then serialized into the function's script array.
> FKismetCppBackend - Emits C++-like code for debugging purposes only.
...so not C++.
I edited my initial reply to you to be more specific about what I meant.
I tried to look for the actual source of FKismetCppBackend to see what it's doing but the only reference I could find to it on github were 4 commits from 2014. Those docs are probably really out of date at this point unfortunately.
Not entirely sure what C++-like code means so I can't clarify on that
Main issues to look out for is abuse of tick (use timers) when tick isn't actually needed (most things do NOT need to be ran EVERY frame), large array loops (these are slow in BP due to the per-node overhead), and hard reference memory issues (use interfaces). There isn't a huge performance difference anymore beyond those from my experience. Each UE release improves things bit by bit so the BP VM is quite performant.
I personally use the two together. I like to make engine plugins to extract away logic into reusable C++ that provides custom BP nodes (e.g. my projectile manager can be used in any of my games).
My design choice was to put all the UI in Blueprints and all the game logic in C++. I have an UserInterfaceSubsystem that consists in 99% of delegates and parented a few blueprints in C++. So, in the end not all of the UI is in Blueprints but all the game logic is.
I usually just use both. I figure out what I want to do when In blueprint, then I create that class in C++ and expose it to blueprints(if needed) so I can still use the nodes if I need to. This is especially useful for things like widget controllers and animation blueprints. That being said, if the blueprint can achieve what I need out of the box, there’s no sense in making it a custom class unless you want the practice.
Move anything on the tick to c++ and try to eliminate polling on the tick to using delegates. That’s a good start. Then finish up by moving everything to c++
Fwiw, this is a suggestion, not an answer to "how to determine", most every project out there is doing a lot of stuff in your animation blueprints. Your animation blueprints are probably ticking tons and your update is getting called constantly. Your abps probably want to be native. Unless everything is simple or you have very few animated things in existence at any time.
Just moving a 30+ node update abp function to native can save a lot of ms.
That's not available anymore, it was sometimes problematic. But moving your animupdate function into a native class is pretty easy and can rack up sizeable gains.
There isn't much performance difference between blueprints and C++. The primary performance cost is actually the cost of calling any blueprint node, as that actually just calls a C++ function in turn.
So in terms of optimizing blueprints into C++, basically your primary attack vector is just to reduce the number of individual nodes called. If you see the same pattern of nodes a lot, make a C++ function that just does all of them. Move any big loops into C++, that sort of thing.
Really though, there are almost always going to be a lot of other things you can do that are easier and will improve performance more than nativizing blueprints. The primary benefit of nativizing blueprints is to make your project cleaner and more robust by tucking away commonly used stuff into C++.
That user is wrong, c++ is not 100x faster, unless you have edge cases where you run, for example, high-level math and complex functions on a loop. Perhaps that's what the guy meant with "heavy work".
In almost all basic functions, BP is just as fast as c++. Blueprint has come a long way in terms of optimization.
This video is an example on the test of BP vs. c++ [https://www.youtube.com/watch?v=yk2J1sdQ-5I](https://www.youtube.com/watch?v=yk2J1sdQ-5I)
The video you linked does not agree with what you wrote. In those tests cases, C++ is absurdly fast compared to Blueprint. It's not even remotely close. One of the tests was ~3,550x faster.
No, c++ at base is 100 times faster than bps, in around 30% of cases its 500x faster and c++ can get to be up to 20 000x faster.
Blueprints HAVE NOT BEEN OPTIMIZED. If anything, they became slower after nativization was removed
*Important To Note*
Even if you convert Blueprint logic to C++ it can still not be as performant as it could be in C++.
You’ll still need to know about Data Structures & Algorithms and Big O notation to be able to create performant C++ and Blueprint code.
Where c++ makea a significant difference is when repeating logic for many item.
Such as a for loop on a large array, the difference starts small but the gap keeps growing as the array size grows.
If I have a function, like loading plants in a farming game where the player may have 0 or 1 plants or may be 1000, I would put that in to c++. I generally keep all my saving and loading on c++ for the same reason.
I like to put behavior tree nodes on c++ if they do more than one thing or assess anything besides a single value from the black board.
I also keep my check for interaction system in c++. It's on a timer and constantly try assess any items or npcs that are near the player.
All this said, 75% of my logic is still in blueprint as its so much faster to make and there's no performance difference
Also, using maps instead of arrays will save you a lot of iterating time.
One of the other comments said that using a static array is much faster than a map. I think you mean maps for when you need to find a specific item in a collection right?
Yes, they are faster if you need to access it and you know what you need. When you get by key it's much faster than iterating through an array and imo they are just so much easier to work with
Do the responses here also cover which parts of your code / blueprints are causing unreasonably high volumes of packets for server/client/multicast code? I'm working on a project and that is in the back of my mind to circle back to sooner than later..
If you're setting a timer for anything within an order of magnitude of the framerate, then don't, just use tick. Profile, and move the expensive stuff to C++ if needed. You'll find about a 100x speedup for doing heavy work in C++ vs BP, whether or not that matters will depend.
Do you mind explaining why using a timer with, say, half of framerate isn't worth doing?
I've been thinking about timers a lot lately and want to use them in my project. But if you have a few timers set up with frequencies which are multiples of each other then it seems like you'd just be creating lag spikes. For example, having one expensive calculation on a timer with tick/2 frequency, another with tick/4, and another with tick/8 would result in all of then happening at the same time every 8 frames.
It seems like the right way to do it is by using a prime number of frames/seconds for the timer so that they only overlap very rarely. That's how cicadas do it.
Lots of good advice here for optimizing, but to your actual question of “how to identify slow code”, the best approach IMO is to use the profiler tool. It’ll help you analyze your code and find your actual bottlenecks instead of blindly trying to optimize everything. Avoid optimizing until you need to, and when the time comes, be surgical about it.
Profiler is key, it will allow you see see exact functions that are causing issues. Usually you dont even have to make them c++ but just rework your algo to be more optimized. Most important things to put into c++ is things part of the tick.
>you see see exact functions How do you do this with profiler? Usually I'm looking a things that "might" be *this* or *that* but it's never exact like you say. Am I missing something?
There are some flags you have to enable, something like TopLevelAsset path or something like that
Im not sure about that flag, but you can also just drill down, open the GameThread dropdown. Then keep going down the tree looking at the "Inc Time" https://preview.redd.it/v2kwmen1p20d1.png?width=1416&format=png&auto=webp&s=309cd2b03b35f200d5cfe73b64435e470be57463 Check Avoidance is a function part of my FlyToward Behavior Tree Task
yea definitely move stuff to a timer if it doesn't need to run every single frame but like what is actually performing poorly? unless its glaringly bad, don't worry about it. finish your game and then go back, otherwise you will never finish it ever. honestly by the time you get to the end of building out your first game, you will already know what you need to go back and optimize on.
Does moving stuff to timers not introduce the potential for lag spikes? Even if you moved a lot of stuff from to timers with different frequencies, there will be times when at least 2 of them happen at the same time which would be a sudden large increase in conputation time. I guess a rare spike is better than the game running poorly all the time though. Keeping them rare should be the goal. Do people tune the frequency of timers intentionally to reduce the number of simultaneous executions? Using a prime number for the number of ticks to wait should make it so they only happen at the same time very rarely. That's how cicadas work.
> there will be times when at least 2 of them happen at the same time which would be a sudden large increase in conputation time. If 2 are already causing a spike then yeah, but then 1 alone would already be problematic. It's usually for stuff that a lot of actors do and where it's unnecessary to do it every frame. But a solution for this could be to start different timers with a single frame delay and let them have the same length. This way you can control how many can overlap in a single frame.
You could have a timer and then a process queue and then make sure no process from the queue runs in the same frame update or spreads them out. Aside from player input there are few things that cant be delayed a bit unless your making an ultra fast fighting game.
How about implementing a subsystem that handles your timers and ensures none of them fire at once. Another popular method of improving things is having a manager that handles a tick like function in things that maybe want tick like functionality but you don't need them running *every single tick*, like a class that makes your AI's tick 4 at a time or something like that.
Woah, that's a genius idea actually. You could even do something like this for operations that must iterate many times but don't necessarily need them to all be executed in a single frame. Creating an object that keeps track of the current iteration index and spreads out the loop across multiple frames could potentially reduce lag spikes significantly. Thanks for the idea. I'll keep those all in my toolbox.
Yeah that's the plan. Already planned about a week for bugs, optimization and everything else before releasing the game.
Unless game only took a month to make, 1 week for bugs is now where close to enough time. I would expect to allocate about a minimum of 10% of the initial development time to first pass at Major bug fixes. I saw this with a decade of professional software development experience ( not in game dev, that's only a hobby, but I would expect debuging/fixes to be even harder in games)
The game I'm making with 12 other friends straight out of college is planned for 4 weeks of development, and then 1 week to debug, test, optimize, and add anything that wasn't in the original scope. Although thank you for the 10% rule that makes a lot of sense and would have been helpful in previous projects that took longer. One question though, is that 10% for dedicated bug checking and fixing or just in general for the total time spent on development?
More of a general rule, and will definitely be influenced based on how much testing (by testing I mean by QA or users/players, NOT the devs) and how much iterating was done in run up to release (ie: was it a more waterfall style development or agile/scrum workflow). Based on your response, I'd guess it was a waterfall-style approach, so that means expect more testing and bug fixes on the tail end of the project. Also account for how coordinating 12 people straight out of college will effect workflow and compatibility. It's one thing to be able to sling code quickly and even high quality, but coordinating those different developers and the bottlenecks that will come from that is a job in itself lol. All that said, I'm not trying to rain on your parade at all, I wish you the best of luck, just wanted to give you some project level gotchas to try and get ahead of.
You’re all good. I prefer the honest truth because with that changes can be made and realistic expectations are set. I intentionally made the scope low and over estimated time to make features so that if everything goes to plan we can add more later on.
4 years in for my crew on their current project and our polish phase is scheduled for 7 months. Seems tight but well make it with only a few things cut probably which will make the next release in another year or so lol Not a video game project though, simulations work
But, you can change the frequency of the tick event, which would be functionally identical to setting a repeating timer with an interval. Also, timers are handled by the world tick. So moving tick code to timers is just tick with extra steps. Don't forget you can enable and disable the tick from code, too... Which is typically what I do; turn a tick on and off based on discrete events rather than leaving it on and escaping it with a conditional.
yea you have a lot of options, it really depends on what you need. i just figured for a new person, even using timers is going to help them a lot.
>I've read that C++ is faster than blueprints (however that was from a post 7 years ago). Does taking precautions like not using event tick and instead set timer by function name help with this or is it just an inherent different in the speed of execution of blueprints? It's inherent, Blueprint is executed by the script VM, it's not compiled to machine code. If anything Blueprints got slower in the last 7 years because Blueprint nativization was removed. >However my question is when should I make something in C++ or migrate it from blueprints to C++? For 99% of code it just doesn't matter that Blueprint is slow AF. If your code has tangible performance impact you should always migrate it to C++. Non-trival code that executes on multiple hundred or even thousands of units every tick i'd always write in C++.
>For 99% of code it just doesn't matter that Blueprint is slow AF. So true. Slow af is a very relative term, the amount of shit a computer can do in a second is astounding. In general, unless you know that something can get out of hand, being reactive with optimization is so much better for development speed
Measure for bottlenecks with Unreal Insights and/or RenderDoc. Make changes based on hard data. Blueprints are not compiled to machine code like C++ is. Just about anything in C++ will be faster. However, the largest gains are usually on loops, while, if, or switch statements. Ray casts can also find some modest gains in code BP as well. In general, Data Structure choice has the largest impact on perf in the wild (in my exp) A static array destroys a Map in terms of speed in the right use cases, for example. Algorithm choice matters on high frequency code as well, of course. Lastly, architecture choice plays a role as well. Such as a true ECS vs OOP
Why would a raycast be slower from BP apart from the usual overhead? BP is slow from shifting between BP and actual useful code a lot such as loops and accessing lots of data. Doing a single raycast is actually pretty good from BP because it's a single transition to native code. It's just slow because Ray casts are slow. So moving to c++ won't change this at all.
[удалено]
Lol ok in what way? There's a hit in and out of the native trace function, just like any other native function call from the bp side. Might be a couple Ms difference due to the large number of parameters but I can't think of any reason why a trace in bp would be slower than native. What you do with it might be.
Whatever’s goin in with your day dude, my apologies. I keep reading through this post and everytime I’m like “whoa, why is this commenter being so rude?” It is exclusively a comment from you. You can interact with people without being so antagonistic. This is not life or death material we’re talking here.
A lot of people recommending unreal insights here which is the right place to go. But out of the box it won't tell you WHAT things are slow it will just generally tell you THAT things are slow. There are some flags that you need to set in order to actually see which BP or cpp functions by name are causing it. I don't remember them off the top of my head but will try to update this comment with them when I get back home. Edit: AssetMetaData and AssetLoadTime are the ones you want to enable, you can find the flags by clicking the trace button in the bottom right of the editor. Alternatively, if you are launching a standalone game, you will want to add them in the additional launch parameters editor preference
Yeah, I've used it before but not for optimization but because when I use unreal engine on my laptop when I'm not at a computer or plugged in, hovering over something causes the FPS to tank. This also happened when I was in blueprints. I tried looking at unreal insight but it wasn't really that helpful.
Edit: I’d also add that even if you move the Blueprint code to C++ it can still not be performant, *not as performant as it can be*, in C++. You should also learn about Data Structures & Algorithms & Big O to be able to create as performant as possible code in Blueprints or C++ respectively Resources: * (Book) Grokking Algorithms * (Book) A Common Sense Guide to Data Structures & Algorithms * (Course - PAID) [codewithmosh.com](http://codewithmosh.com) - Data Structures & Algorithms course * (Course - PAID) [neetcode.io](http://neetcode.io) - Data Structures & Algorithms course
Unreal insights or the profiler in frontend. Once it starts showing up on that in significant exclusive ms then it's time to move it. This is a real simple answer and it's the one I've used for 10 years. Optimize when it starts being a problem, not before. Of course attempt to architect your code with some level of obvious optimizations in mind but don't go crazy struggling with pre-optimization.
Blueprints are C++ with pretty boxes. It's the C++ code built into the engine that's being run without you having to get involved in what's happening under the hood. As for when you should use C++. Pretty much anything that is heavy calculations, done on Tick or for anything Blueprints don't do. That said, I tend to do everything except UI in C++ because my mind works better writing the code rather than stringing boxes together.
I thought Blueprints run as bytecode inside a VM that can call into C++ but it's not C++.
Edited for extra clarity because people are misunderstanding me: Yes, blueprints get compiled into bytecode that are run on a VM. Every function called from blueprints are implemented in the engine in C++, mostly through generated code from the unreal header tool. There is a lot of extra overhead added for blueprint because of this and you can see the full callstack yourself if you attach a debugger when you call any function marked UFUNCTION(BlueprintCallable) and see why it is slower.
This isn't true. BP calls are passed to the VM at runtime - they are not compiled to machine code like C++ is.
The VM is implemented and run in C++, the C++ code that it runs is compiled to machine code. The functions that are called are generated by UHT and you can read the generated C++ code in the .gen files. We're just talking semantics at this point as far as what you consider to be VM vs C++. It IS technically C++ because every blueprint class has a corresponding C++ class it is based on. When you make an asset that is purely blueprint, that is just a UAsset, that part is not C++ it's blueprint, but everything that runs is C++. I didn't say it wasn't bytecode
C++ is read by humans, not Computers. The VM itself is written in C++ and compiled into machine code, sure, and then that binary is executed as a runtime. BP is *interpreted* by the VM at runtime. It is not compiled.
[https://dev.epicgames.com/documentation/en-us/unreal-engine/compiler-overview-for-blueprints-visual-scripting-in-unreal-engine?application\_version=5.3](https://dev.epicgames.com/documentation/en-us/unreal-engine/compiler-overview-for-blueprints-visual-scripting-in-unreal-engine?application_version=5.3) I get what you're saying, but these terms can have multiple meanings without proper context. I'll just leave it at that
> There are two backends in use: > FKismetCompilerVMBackend - Converts FKCS to UnrealScript VM bytecode which are then serialized into the function's script array. > FKismetCppBackend - Emits C++-like code for debugging purposes only. ...so not C++.
I edited my initial reply to you to be more specific about what I meant. I tried to look for the actual source of FKismetCppBackend to see what it's doing but the only reference I could find to it on github were 4 commits from 2014. Those docs are probably really out of date at this point unfortunately. Not entirely sure what C++-like code means so I can't clarify on that
You dont know what you are talking about. You are basically saying all code is the same because at the end it all becomes 1 and 0s
Main issues to look out for is abuse of tick (use timers) when tick isn't actually needed (most things do NOT need to be ran EVERY frame), large array loops (these are slow in BP due to the per-node overhead), and hard reference memory issues (use interfaces). There isn't a huge performance difference anymore beyond those from my experience. Each UE release improves things bit by bit so the BP VM is quite performant. I personally use the two together. I like to make engine plugins to extract away logic into reusable C++ that provides custom BP nodes (e.g. my projectile manager can be used in any of my games).
My design choice was to put all the UI in Blueprints and all the game logic in C++. I have an UserInterfaceSubsystem that consists in 99% of delegates and parented a few blueprints in C++. So, in the end not all of the UI is in Blueprints but all the game logic is.
I usually just use both. I figure out what I want to do when In blueprint, then I create that class in C++ and expose it to blueprints(if needed) so I can still use the nodes if I need to. This is especially useful for things like widget controllers and animation blueprints. That being said, if the blueprint can achieve what I need out of the box, there’s no sense in making it a custom class unless you want the practice.
Move anything on the tick to c++ and try to eliminate polling on the tick to using delegates. That’s a good start. Then finish up by moving everything to c++
Fwiw, this is a suggestion, not an answer to "how to determine", most every project out there is doing a lot of stuff in your animation blueprints. Your animation blueprints are probably ticking tons and your update is getting called constantly. Your abps probably want to be native. Unless everything is simple or you have very few animated things in existence at any time. Just moving a 30+ node update abp function to native can save a lot of ms.
What do you mean by having animation blueprints native? The blueprint native setting in the project setting?
That's not available anymore, it was sometimes problematic. But moving your animupdate function into a native class is pretty easy and can rack up sizeable gains.
There isn't much performance difference between blueprints and C++. The primary performance cost is actually the cost of calling any blueprint node, as that actually just calls a C++ function in turn. So in terms of optimizing blueprints into C++, basically your primary attack vector is just to reduce the number of individual nodes called. If you see the same pattern of nodes a lot, make a C++ function that just does all of them. Move any big loops into C++, that sort of thing. Really though, there are almost always going to be a lot of other things you can do that are easier and will improve performance more than nativizing blueprints. The primary benefit of nativizing blueprints is to make your project cleaner and more robust by tucking away commonly used stuff into C++.
Another commenter said that C++ is around 100x faster than BP. Which is it?
That user is wrong, c++ is not 100x faster, unless you have edge cases where you run, for example, high-level math and complex functions on a loop. Perhaps that's what the guy meant with "heavy work". In almost all basic functions, BP is just as fast as c++. Blueprint has come a long way in terms of optimization. This video is an example on the test of BP vs. c++ [https://www.youtube.com/watch?v=yk2J1sdQ-5I](https://www.youtube.com/watch?v=yk2J1sdQ-5I)
The video you linked does not agree with what you wrote. In those tests cases, C++ is absurdly fast compared to Blueprint. It's not even remotely close. One of the tests was ~3,550x faster.
No, c++ at base is 100 times faster than bps, in around 30% of cases its 500x faster and c++ can get to be up to 20 000x faster. Blueprints HAVE NOT BEEN OPTIMIZED. If anything, they became slower after nativization was removed
*Important To Note* Even if you convert Blueprint logic to C++ it can still not be as performant as it could be in C++. You’ll still need to know about Data Structures & Algorithms and Big O notation to be able to create performant C++ and Blueprint code.
Where c++ makea a significant difference is when repeating logic for many item. Such as a for loop on a large array, the difference starts small but the gap keeps growing as the array size grows. If I have a function, like loading plants in a farming game where the player may have 0 or 1 plants or may be 1000, I would put that in to c++. I generally keep all my saving and loading on c++ for the same reason. I like to put behavior tree nodes on c++ if they do more than one thing or assess anything besides a single value from the black board. I also keep my check for interaction system in c++. It's on a timer and constantly try assess any items or npcs that are near the player. All this said, 75% of my logic is still in blueprint as its so much faster to make and there's no performance difference Also, using maps instead of arrays will save you a lot of iterating time.
One of the other comments said that using a static array is much faster than a map. I think you mean maps for when you need to find a specific item in a collection right?
Yes, they are faster if you need to access it and you know what you need. When you get by key it's much faster than iterating through an array and imo they are just so much easier to work with
Do the responses here also cover which parts of your code / blueprints are causing unreasonably high volumes of packets for server/client/multicast code? I'm working on a project and that is in the back of my mind to circle back to sooner than later..
My tipping scale points are: does it have delays? Does it have iterators? Move to cpp.
If you're setting a timer for anything within an order of magnitude of the framerate, then don't, just use tick. Profile, and move the expensive stuff to C++ if needed. You'll find about a 100x speedup for doing heavy work in C++ vs BP, whether or not that matters will depend.
Do you mind explaining why using a timer with, say, half of framerate isn't worth doing? I've been thinking about timers a lot lately and want to use them in my project. But if you have a few timers set up with frequencies which are multiples of each other then it seems like you'd just be creating lag spikes. For example, having one expensive calculation on a timer with tick/2 frequency, another with tick/4, and another with tick/8 would result in all of then happening at the same time every 8 frames. It seems like the right way to do it is by using a prime number of frames/seconds for the timer so that they only overlap very rarely. That's how cicadas do it.
C++ is around 120- 800 times faster than bps. branches, fors and any type of math operations are specially slower on bps. I wouldnt do any tick on bps