Download

Add More efficient variable types

Hello, how about to add more efficient data types that will consume less memory?

Like tinyint instead of just big integer that eats a lot of memory if just need to store small values. Or varchar instead of string for holding small values like player names, level names, etc. Why do I need such big values that allocate so much memory? This is against optimization. While I am not computer scientist and don’t understand a lot, I think that you need to add this variable types since every kind of programming software let it be database development or android studio they all have different
data types options for a better optimization.

I don’t know if it will be noticeable performance boost but having appropriate sized data types is within good programming practices and I think that nowadays people forget about optimization.
​​​​​​​
Don’t get me wrong
I respect Unreal Engine a lot and it is absolutely the best engine ever. It is industry standard, serious, powerful, developers are great and care about community. I just want to suggest a way to improve it one aspect

In your c++ code you can use what data types you want. For blueprint code this wouldn’t affect in any measurable way or at all. What is your use case or is this just some kind of premature optimization effort?

Do you mean FString? If yes, I’d recommend using FName where possible in order to save some memory… Although it’s probably more noticeable on the engine level.
https://docs.unrealengine.com/en-us/Programming/UnrealArchitecture/StringHandling/FName

Even if you consider FName as too expensive, I wouldn’t expect more string types exposed to editor and blueprints. We already got FText, FString, FName.

use C++ if you want performance. Easy as that.

The open source code for the engine is there for things like this! You typedef your integer to be the type you like, rebuild the engine and all plugins you have source code and your are done! Ofc pre-build plugins out-there which you don’t have source code are useless unless you purchase their source code too.

PS: Unfortunetelly many systems are not economic at all in computers nowadays, an example: create a simple text file using just 1 character and see how much it takes away from your hard drive… a lot! It will consume exactly the minimum amount of data cluster which usually is bigger as bigger is the total storage.

You will never ever need that optimisation on modern hardware, ever.

On 4.20 there is actually two byte strings instead of 4 byte for mobile. Engine team is doing great work for memory optimization because of mobile Fornite and Fortnite servers. There are quite big of overhead there that can be shaved. But using byte for player hp instead of integer does absolute nothing. There are alignment requirement that prevents that kind of things to help at all.

​​​​​​I don’t know c++ and c++ is a great loss in terms of development performance as I need to compile each thing in a separate application, it’s very time cobconsum and outdated approach for development
Doing everything in code would be a nightmare for bigger projects as you get lost easily, you can’t even create a big *** comment like you do in blueprints
Sure if you are making a small game do it in code, but serious projects are better to be done with blueprints. I have like 100 variables in one umg class, and around 300 in save game, and imagine managing that through code. Nearly impossible, very time consuming, stupid and unprofessional.

That’s why we get badly optimized games. Because of that attitude. “Hardware will manage that”. You are just unethical.

I think @DamirH is talking about the active search for optimization when is not necessary, specially if the compiler takes care of most cases. He is not talking about types of optimizations that any mid/senior programmer should know and use without even thinking about it: inlining, optimized branches, no loops overheads, arithmetic tricks, setting up the correct data structure, correct use of static and const, …

This post is enough to show me that you are either baiting for reactions or genuinely and hopelesly don’t have even the slightest hint of a clue of what you’re talking about. Both are sufficient reason to stop wasting my time and never interact with you again while I’m alive, have a good one.

You have zero clue what you are talking about and yet you claim it to be unprofessional and stupid.

Look man you are not right

Where exactly I am having no clue? What are your proofs? You are just experiencing a denial syndrome. That you your hard-gained knowledge, your outdated approach that you were proud of is a joke. You have been showed the prove into your face, you are experiencing a shock. I hope you understand that this was an expected result.
Low level jobs like website development or gamedev where you don’t Invent anything new will become visual. In a few years there will be like complete games templates as there is no need in recreating the wheel over and over again 22000 times. Expect to lose your job as a game programmer within 5 years maximum.

I would actually imagine 300 variables being far easier to manage in C++, and anybody with that many vars in one place in BP would know why.

Definitely baiting.

If you have 100+ variables in a single class, regardless of programming language, you have little background to call anything “unprofessional”.

You have no clue what you are talking about. If you ever worked on a medium sized project, solely menu umg contains more than 100. Go get a job

Let me explain WHY this doesn’t matter, instead of joining this childish duel of insults…

What you fail to understand is this:

“Variable Types” in Blueprints are UObjects. Every single one of them.
Suggesting such insignificant improvement for type sizes in Blueprints tells you aren’t aware of that and this is why some people are posting these unnecessarily aggressive replies.

Now take a look into…
​​​​​Runtime/CoreUObject/Public/UObject/NoExportTypes.h
Runtime/CoreUObject/Public/UObject/UObjectBaseUtility.h
Runtime/CoreUObject/Public/UObject/UObjectBase.h

Then be shocked by how large an UObject actually is…

The only place where something like that would matter is in low level networking layer, still, very specific cases.

This is why your suggestion doesn’t really make sense; that would change nothing.

The only valid cause for variable size is when you are transmitting them over internet - mmo, for an example.

But if you are talking about data size efficiency, it is very negligible in term of size and performance.
For cpu performance, we are much more concerned about data alignment dan cache-miss etc

When I need to be memory-compact, I will sometimes use bytes, or bitfields.

Both of these options are available in blueprints. You cannot get much more memory efficient than that.