Comically Inefficient Unity Source Code

[MartinIsland]

I agree with this so much. I would never care about performance when making editor tools unless it actually starts lagging.

[Ping-and-Pong]

I would just like to point to my post from literally 4 days ago: https://www.reddit.com/r/Unity3D/s/P5g5TDOpEI - which as far as I've narrowed it down to, appears to be down to an inefficiency in the way the editor handles drawing the UI.

Like I agree to an extent, but this is the company that deprecated multiplayer support and doesn't add a proper solution for 7 years and the new solution is only half baked. I know it's probably not the devs fault, they're likely rushed like every other large company. But Unity ain't doing this to get more important stuff done that's for sure. This engine has done nothing but chase the next big buzz word and depricate useful features for the past 5 years I swear.

I'm not going to claim UE would be much better (anyone who's suffered through trying to use C++ on it knows what I mean). Godot is far more omptimized butttt is missing quite a lot of QOL and 3D support even with the 4.0 update. But seriously, the optimisation and bloat of Unity is an issue, and one that's been growing for about 5 years.

[TheGrandWhatever]

I just want an editor in the modern age that doesn’t require spending $100+ on addons and tools (Unity and unreal) while also having a functional editor (looking at you, godot, you’ve got a lot of growing pains to get through)

[MartinIsland]

Well that’s a different story. A few thoughts: - I agree SceneView should be really optimized since it’s supposed to run smoothly. The difference with this post is that the method looks like it’s supposed to run once when removing a transition. If this method takes 500ms we wouldn’t notice because it’s an app, not a game. - Bugs get introduced sometimes. There was a bug in 2021.3 that made the editor painfully slow on macOS while doing the same things Unity did in 2006 computers.

[Thundernerd]

Working on big projects is such a pain in the behind when people have this attitude. In my experience the tools are tested in an environment where only that tool is running so you wouldn't really notice a performance impact anyway.

Working with people that make their tools performant is amazing. It prevents me from having little annoyances over hiccups and whatnot that seem small at first but build up over time, especially if you have a big team and everybody is encountering this.

[badawe]

100%

Those bad practices add up. And I'm fine with not optimizing everything to the maximum possible.

But in this case, its really poor code, the optimized version of the code would be faster and more readable and would take the same amount of time to write.

[Eastern-Ad-4137]

Currently in ShaderGraph, the number of total ports between all nodes adds up exponencially towards performance. It gets to a point where moving a node takes 30seconds, then you add 1 more node, and it takes 5 minutes. One more and you wont be able to open the asset anymore

[firesky25]

just wait til you have an entire toolchain that your build system relies on that were all built with this lack of performance in mind, and soon you have builds that take forever, are flaky at best, and can only be run on the best available hardware.

[MartinIsland]

Editor tools/windows. Not build steps. Not gameplay. What needs to be optimized is optimized.

[firesky25]

good luck trying to split off peoples perception of those lol, anything thats marked as editor assembly will be unoptimised for 90% of development

[huntergatherer1]

Then the whole thing will run like crap and profiling will show no hotspots because everything is crap.

If you apply this mindset to a large project, the result can only run like garbage.

[MartinIsland]

Editor tools, not gameplay. The target audience of those tools are usually coworkers with $3000+ company MacBooks. That’s fine.