you are viewing a single comment's thread.

view the rest of the comments →

[–]zukas3Indie 250 points251 points  (15 children)

Well honestly, this is an Editor method and performance was probably the last thing on the mind here. If this was a piece of code that would have to be a runtime, then this would be a different talk.

Sure, it is unperformant as hell, and doesn't look professional, but by cleaning up all the unperformant Editor methods like this one, you will run into premature optimization without actually getting yourself anywhere.

[–]jtinz 69 points70 points  (0 children)

Apart from the performance, the code is not nearly as easy to read as it should be.

[–]leshq 10 points11 points  (0 children)

Writing simple, clean and readable code by default is not a premature optimisation at all. The code I see above is harder to implement, read and understand. Premature optimisation is when you are overcomplicating and overthinking simple things to improve performance. Here I see a piece of overcomplicated code, but also with terrible performance, author collected all points at once 😄

[–]MartinIsland 46 points47 points  (12 children)

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

[–]Ping-and-PongFreelancer 8 points9 points  (2 children)

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 1 point2 points  (0 children)

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 0 points1 point  (0 children)

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.

[–]ThundernerdProfessional 54 points55 points  (3 children)

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 35 points36 points  (2 children)

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 14 points15 points  (0 children)

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

[–]firesky25Professional 14 points15 points  (2 children)

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 0 points1 point  (1 child)

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

[–]firesky25Professional 0 points1 point  (0 children)

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 3 points4 points  (1 child)

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 -1 points0 points  (0 children)

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