Extreme Memory Usage

[adoby]

Hey,

We are a small studio looking for a replacement for Playmaker.
Problems:
Compile Time when creating new scripts
Memory usage was 150MB (on mobile) just Playmaker (about 4000 fsms)
Perfomance in Editor is abysmal

We where testing UScript, FlowCanvas, Playmaker and manual Scripting to see what the differences are.
Conclusion: only Scripts and UScript are functional in our projects.

Test:
Every tech used to create the same behaviour.
Set the position of transform to “Random.insideUnitSphere” on each update on 1001 Objects.

Editor:
Playmaker: 8-9ms, 20MB + (memory leak, why? idk)
UScript: 1.8ms, 20MB
FlowCanvas: 12ms, 70MB
Scripting: 0.8ms, 20MB

Build:
Playmaker: 3ms, 6.3MB
UScript: 1.2ms, 2MB
FlowCanvas: 1ms, 25MB
Scripting: 0.8ms, 1.2MB

Conclusion:
Playmaker performance unusable, memory ok but not good (gets way higher with more complex fsms)
Flowscript unusable in editor (2k scripts with more complex functions took 50ms in playmode each frame), memory usage waaaay to high in editor and build

UScript usable in both Performance and Memory but takes longer to work with (compile times)
Scripting as expected is the best solution when looking only at performance and memory.

Can we expect any massive? improvements in both editor performance and memory usage in the future ?

Unusable in the current state for us.

[rixter757]

Interesting post.

I think the key here is C# code generation. uScript is the only VS tool from the above that produces C#. The only other I can think of is Blox2, you might want to compare it also. I’m not sure if C# is on the FlowCanvas roadmap?

Other factors here should include project size & the time to create code, based on experience & tool capability. If you can code, you should. No-one would argue with that. Since you are here, you probably require less complication than actual coding for your team. So you have to weigh up the pro’s and con’s.

The best balance is to create the complicated functions with C# and show your designers how to interact with VS and code reflection.

Can you post any code snippet like-for-likes against each other? I would personally like to see how each construct compares.
My limited experience is that FlowCanvas is much easier to learn than the other 2 VS tools, with far fewever nodes needed to accomplish the most basic tasks. Again, your like-for-like would make for a great read.

Rix

[adoby]

From my side, I wouldn’t use any visual coding at all.
But i can not work on all projects at onces.

Artists often ask for a simple way to add new functionality on the fly (like button clicks, or animation triggers)
I can not recode all of that (i wouldn’t have time for anything else).

So we need a visual scripting tool (sorry but blox is not the way to go :P)

FlowCanvas has a lot of very good features like instant code reflection thingies which designers can use instantly.
Playmaker just needs to much work (creating custom actions for everything is not efficient)

We would really like to use flowcanvas in production, but the drawbacks on performance and memory are to high.

UScript on the other hand is cool, but reflection is very basic (you can’t even set the position of a transform without custom action?) and compile time limits efficiency by a lot.

[Gavalakis]

Hello,

The editor is naturally slower than the build specifically for debugging. If you want to make the editor resemble the performance a bit closer to the build, you can open up BinderConnection.cs AND BinderConnection(T).cs and comment out the define at the very first line of the scripts.
As for memory usage, can you please post a screenshot of that? I’ve redone the test here for 1001 flowscripts and the garbage allocation was 0, as well as the “scene memory” usage in the profiler was 1.7MB. (with the defines commented out as explained before).

Thanks.

Join us on Discord: https://discord.gg/97q2Rjh

[adoby]

Here.

You have to look at “ManagedHeap.UsedSize” under “Other” if you are looking at Detailed view.
But we just look at “Mono” at the Simple View which is sufficient.

I Redone all the tests to have clean and comparable samples.
This simply shows that FlowCanvas uses way to much Memory compared to simple scripts with the same logik.
As well as bad performance in editor.

Here:
FlowScript overview
Editor Performance

Attachments:

You must be logged in to view attached files.

[adoby]

New:
FlowCanvas in Build
Script Overview
Script Performance

Attachments:

You must be logged in to view attached files.

[adoby]

Here:
Test Project
(Commented out the 2 defines after doing the tests)

Attachments:

You must be logged in to view attached files.

[Elliot Bulmer]

I don’t see any visual scripting language as a complete replacement for code. My approach has been to start with VS and move to code when I think I need performance or if the logic I’m trying to express is simply to complicated to represent visually (constraint solving is a good example).

[adoby]

We are not looking for a “complete replacement”.
We are looking for a system which our artists or even us coders can use to add quick functionality (as said above).
The base app will be coded.

But look at the FlowScript I made. Its like 4 States (less then nothing?).
Using nearly 30MB just for that is ridiculus.

We are looking at a worse case.

[Gavalakis]

Hello,

I don’t know why you are worrying about the editor memory usage so much, since the build/runtime one is important. The editor is using visual debugging and some other things which do not enter the build, but like I posted above, you can disable these if you want by commenting out the defines. Also it seems that 30MB is the total memory usage, not the one used by FlowCanvas alone. I tried an empty scene and memory usage was 10-12MB and only after instantiated 1000 flowscripts memory usage got to 30MB.
With all that said, I will certainly take a look at what can be done to improving memory usage, but the fact that in build FlowCanvas has zero allocation for GC and only takes 0.2ms more than actual scripting and faster than all the rest according to you test above, I think it’s quite good.

Thanks.

Join us on Discord: https://discord.gg/97q2Rjh

[adoby]

We don’t care about editor memory usage, but editor performance.
But thats okay as long as the build works, which it doesn’t !

Compare ScriptInBuild vs FlowCanvasInBuild and you can see, that 30MB IS NOT the “total memory usage”
But only the usage of FlowCanvas alone.

Here:
Empty Scene performance and memory

Unity alone 360kb and scripts 80kb more
As we can see easily, FlowCanvas uses about 26,7MB more memory in build than anything else.
All Tests done with Unity 5.3.4f btw.

Attachments:

You must be logged in to view attached files.

[Gavalakis]

Hello again,

It’s a bit bold to say that ‘the tool does not work’ while it does for many people already. In each tool there are gives and takes. FlowCanvas is the fastest with zero GC, but has more memory usage. Other have less memory usage but are slow or have allocations. This is the current state of the tool right now, but rest be assured that I constantly try to improve the tool as well as it’s performance like stated before.
By all means, if FlowCanvas does not meet your needs, send me an invoice ID and I can refund.
I’m really sorry, but I can’t think of anything better to respond right now, other that the fact that I am constantly improving the tool as best as I possibly can and that I will also take a look at this front as well.

Thanks.

Join us on Discord: https://discord.gg/97q2Rjh

[rixter757]

I’m unsure of the point here. Are we talking RAM or Storage?

30Mb doesn’t seem like a deal breaker to me, either way. If the 30Mb is exponentially increasing, then fine… but I’m doubting it.

So Flowcanvas is based on an Intepreter of sorts, a package that needs shipped with the product. So what? All I’m reading is “fastest with zero Garbage Colection”. I’ll take that any day instead of having to code everything. Time is money.

I say this is a closed case. Keep up the great work Gav, working on the continuing improvements you already are.

Adoby, I don’t know what you expect from such a tool for such a cheap price. This is best in class for us intermediate coders/indies. Nothing else compares in terms of speed of development, ease of use, learning curve, code reflection, integration with a Behaviour Tree, support which is your personal ticket to speak with the lead programmer of the tool!! How much do you think it would cost to hire a programmer to answer your questions? Subtract that from what you paid. Gav answers questions like these with professionalism… and equally importantly with an openness to accommodate.

I don’t mean to sound like I am attacking you, I hope you stick around & help the community with your experience. Just know that this tool is what it is, fundamentally sound and continually improving. If I could write code like this, I’m sure my gaming idea’s would be earning me a lot of money.

Adding 30Mb on top of your project? Small potatoes.

Rix

[adoby]

@Gavalakis
It’s a nice tool, for small projects. but we are not looking at small projects here.
We can’t just use a tool and find out mid-development that we get memory problems.

Thats why we made the tests and try to get support. If it’s not foreseeable to fix the high memory usage, then thats a nogo in the long run.
It’s totally nice for smaller projects and I’m not saying that you coded something bad.
FlowCanvas is powerful and works better than most of the other tools I used in terms of compile time and integration.
We probably just hoped that there would be a playmaker replacement/blueprint equivalent that wouldn’t have a major drawback.

@rixter
Talking about RAM, its increasing linearly.
Small test with 2000 flowscript doubled the RAM usage as well.
And our test uses a very small flowScript, you would need way more states to create a working app.
We can’t make a real world experiment, that would take too much time.

Have a nice day/night
We may take another look at it.
Maybe you find something that lowers the memory usage.
E.g. Editor properties like Descriptions, Names of states etc. in the build.

[rixter757]

Adoby,

Thanks for your reply & understanding where I was coming from.

Now, here is some information that you are probably not aware of… go back to the Unity store and search for Visual Scripting, order them by Updated (or just search for “Nottorus”). You will find a very new player on the market, Nottorus. It is the ultimate programmers visual scripting tool. Click on the Unity forum thread for a conversation I am engaged in, then make your decision. It is ultimately designed for programmers, but you might be interested. It is more expensive, but very maybe you could train your designers with this. I would mention that it is probably equivalent to training someone to code. Or as a better analogy, it is EXACTLY Blueprints for Unreal. The added twist? It converts C# to nodes. OMG!!

Personally I love it, but it won’t replace FlowCanvas for me. With Nottorus, you have to make explicit nodes for every line of code you would write. With FlowCanvas, it cuts out how much you need to graph, automatic casting etc. Pros and cons. I’ll buy Nottorus for fun as a hobby and ultimately teach myself C# further, but I’ll use Flowcanvas to get the job done quicker.

I wish you good luck with your project, and success with tools that lead you there.

Rix

[Author]

Posts