You hit Play. Everything feels smooth. Then suddenly… 120 FPS drops to 40.

So you do what most of us do. You blame the graphics.

I used to do the same. Turn off shadows, tweak lighting, simplify materials. Sometimes it helped. Most of the time, it didn’t. Because the real problem wasn’t what I thought it was.

In my experience, the usual culprits are way less obvious. Too many draw calls. Scripts quietly doing work every frame. Small memory allocations building up until the garbage collector kicks in at the worst moment.

That’s the trap. What looks expensive usually isn’t. And what’s actually hurting performance is often hiding somewhere you’re not even checking.

Most Unity performance issues aren’t that hard to fix. They’re just easy to misread.

So before you start turning things off at random, there’s one thing you need to do first.

Stop guessing. Open the Profiler.

If you’re not using the Unity Profiler yet, this is where everything changes.

Because right now, you’re probably guessing. And guessing feels productive… until you realize you just spent 2 hours optimizing the wrong thing.

The Profiler shows you exactly where your frame time is going. Not what you think is slow. What’s actually slow.

Open it. Hit Play. Look at a single frame.

The first thing you want to figure out is simple:

Are you CPU-bound or GPU-bound?

If your CPU time is high, the issue is usually scripts, physics, or too many objects being processed. If your GPU time is higher, then yeah, now you can start blaming shaders, lighting, or overdraw.

This distinction matters more than anything else. Seriously.

I once spent an entire afternoon optimizing materials because the scene looked heavy. The problem? A single script calling GetComponent() inside Update() across 200 objects. Fixing that gave me more FPS than all the shader tweaks combined.

What to actually look at (without getting overwhelmed)

The Profiler can feel like a lot at first. It is. Don’t try to understand everything.

Start with these:

• CPU Usage → Expand “Scripts” and “Rendering”

• Rendering → Check draw calls and batches

• Memory → Watch for spikes, not just totals

That’s enough to catch most problems.

Also, quick tip. Don’t trust the Editor too much. It adds overhead, and numbers can be misleading. If something looks borderline in the Editor, it might be fine in a build… or worse. Always verify with a build when things matter.

A small mindset shift

You’re not optimizing randomly anymore. You’re forming a hypothesis.

“Something is slow” becomes
“Scripts are taking 18 ms because of X”

That’s how you actually fix performance.

And once you start doing this, patterns show up fast. You’ll begin to recognize the usual suspects without even digging too deep.

Which brings us to one of the biggest ones.

Draw calls are probably hurting you more than you think

At some point, you’ll open the Profiler, check Rendering… and see a number that doesn’t look that scary.

Then you realize your game is still struggling.

That number? Draw calls.

Here’s the simple version. Every time Unity tells the GPU to render something, that’s a draw call. And each one comes with overhead. Not huge on its own, but stack a few hundred or thousand together and your CPU starts to choke.

That’s why scenes with “not that many objects” can still run badly.

I’ve seen projects with 300–400 objects drop frames just because each object was rendered separately. No batching, no instancing, just a long list of draw calls piling up every frame.

Why this happens

Unity can’t magically group everything together. Objects with different materials, shaders, or settings often get rendered one by one.

So even if two meshes look identical, they might still cost you two separate draw calls.

Multiply that across your scene and… yeah. It adds up fast.

The easiest wins (that most people miss)

Static batching is usually the first thing to try.
If objects don’t move, mark them as static. Unity can combine them behind the scenes.

It works great for environments. Buildings, props, level geometry. Just don’t go overboard, because it increases memory usage. There’s always a tradeoff.

Dynamic batching sounds helpful, but it’s limited.
It only works on small meshes and comes with its own CPU cost. I don’t rely on it much anymore.

GPU instancing, though… that’s the good stuff.

If you’re rendering many identical objects, like trees, crates, or repeated props, instancing lets the GPU handle them in a single draw call. Same mesh, same material, drawn many times.

I’ve seen scenes go from hundreds of draw calls to a handful just by enabling instancing on the right materials.

A quick reality check

Reducing draw calls isn’t about hitting some magic number.

It depends on your target platform. A PC might handle thousands. A mobile device? Not even close.

What matters is this: if your CPU time is high and rendering shows a lot of batches, this is one of the first places to look.

And once you start paying attention to it, you’ll notice how easy it is to accidentally create hundreds of draw calls without realizing it.

Same mesh. Different material. New draw call.

Again and again.

Your scripts might be doing “tiny” things that add up to a big problem

Draw calls get a lot of attention. Fair. But if your CPU usage is high and your rendering stats look okay, I’d put money on scripts.

Not one big obvious script either. The quiet kind. The “it’s only a little check” kind. The ones you copied around your project until they exist on 80 GameObjects.

Unity will happily run every Update() you give it. Every frame. Forever.

And that’s where things go sideways.

The classic: death by Update()

If you have 200 objects with Update(), even a small piece of work adds up fast.

A few common offenders I keep seeing:

• Calling GetComponent() repeatedly in Update()

• Doing FindObjectOfType, GameObject.Find, or string-based lookups at runtime

• Building strings for UI every frame

• Running physics queries constantly when you don’t need to

• Using LINQ in hot paths because it “looks clean”

None of these are automatically evil. They’re just expensive when you do them 60 times a second across a bunch of objects.

What to do instead (without rewriting your whole game)

Start with boring fixes. They’re boring because they work.

Cache references.
If you need a component, grab it once in Awake() or Start() and store it. Don’t fetch it every frame.

Move logic out of Update() when you can.
A lot of gameplay logic doesn’t need per-frame checks. Use events, timers, coroutines, or “only when something changes” patterns.

Throttle checks.
If you must poll something, do it 5 times a second, not 60. Most players won’t notice. Your CPU will.

Turn things off.
If an enemy is far away, disable its AI, animation, or even the whole GameObject. This feels obvious, but people forget. I forget sometimes.

A quick profiler habit that saves time

In the Profiler’s CPU view, expand Scripts and look for:

• A script taking a lot of time in a single frame

• Or lots of scripts each taking a tiny slice

Both can be problems. The second one is sneakier.

If you see 2–3 ms spent across “small” scripts, that’s already a big chunk of your 16.6 ms budget for 60 FPS.

And this ties into another performance problem that looks random at first but has a clear cause.

Memory spikes.

Beyond core optimization, using the right tools and plugins can also make a big difference in how efficiently your project runs.

The stutters that feel “random” are usually memory and garbage collection

If your game isn’t just slow, but stuttery… welcome to the world of garbage collection.

This is the classic symptom:

• FPS seems fine most of the time

• then every few seconds you get a tiny freeze

• and it feels completely unpredictable

It’s not unpredictable. It’s usually GC.

Unity uses a managed runtime, which means it allocates memory for certain things (objects, strings, arrays, boxed values), and eventually the garbage collector cleans that memory up. Cleaning up is good. The problem is when it happens mid-game and steals a chunk of frame time.

You’ll see it in the Profiler as spikes in GC.Alloc and big jumps under GarbageCollector.

The sneaky sources of allocations

Some allocations are obvious. Many aren’t.

Common ones I keep running into:

• Building strings every frame (especially for UI like “Score: 12345”)

• Creating new Lists, arrays, or dictionaries inside Update()

• LINQ calls in gameplay loops (clean code, expensive runtime)

• Calling APIs that allocate under the hood (some physics queries, some mesh access patterns)

• Instantiating and destroying objects constantly (particles, bullets, enemies)

The worst part is how innocent it looks in code. A single “new List” inside Update can be fine… until it’s inside 50 objects running at 60 FPS.

What actually works

Track allocations first.
In the Profiler, watch GC.Alloc per frame. If it’s non-zero during gameplay, you’ve got something to fix.

Stop creating garbage in hot paths.
Reuse lists. Keep buffers around. Cache references. Avoid per-frame string formatting.

Be careful with UI text updates.
If you update a UI label every frame, you’re basically asking for allocations. Update it only when the value changes, or at a slower rate. Players don’t need 60 updates per second for a score counter.

Use object pooling.
If you’re constantly spawning and destroying things, pooling can be a night-and-day difference. Bullets, enemies, hit effects, even UI popups. If it appears often, pool it.

I’ll be honest: pooling can make your code uglier. It’s not as neat as Instantiate/Destroy. But it’s one of those “ugly but reliable” performance tools.

When this advice doesn’t apply

If you’re making a tiny PC-only game with simple scenes and you’re not seeing stutters, you might not need to obsess over allocations. Some teams waste time here before it matters.

But if you’re targeting mobile, WebGL, VR, or anything where frame pacing matters a lot… you can’t ignore it. The player will feel those spikes even if they can’t explain them.

Next up is a performance issue people underestimate constantly because it looks harmless.

UI.

UI can tank your frame rate even when “nothing is happening”

UI feels harmless because it’s just text and icons, right?

Yeah… not always.

Unity UI (the classic Canvas system) can get expensive fast, and the worst part is you often don’t notice until late. You add a few panels, some animated buttons, a scrolling inventory, a bunch of text elements, and suddenly your frame time has these weird spikes whenever UI changes.

The big gotcha: Canvas rebuilds

Here’s the thing Unity doesn’t shout loudly enough: when a UI element changes, Unity may decide to rebuild the Canvas. That rebuild can be cheap or brutal depending on how much UI lives under that Canvas.

So if you have one giant Canvas that contains your entire HUD, menus, inventory, tooltips, and random debug text… changing one tiny number can trigger more work than it should.

A classic example: updating a score text every frame.

It looks innocent. It’s not. You’re forcing layout and graphic updates constantly. Sometimes you’ll see it as CPU spikes under UI or Canvas-related markers in the Profiler.

What I do in most projects

Split your Canvases.
This is the single biggest practical fix.

• Put your static HUD (health bar frame, icons, things that rarely change) on one Canvas.

• Put frequently changing stuff (score text, ammo count, dynamic lists) on another Canvas.

• Put menus on their own Canvas entirely.

That way, when something updates, Unity rebuilds a small Canvas instead of your whole UI universe.

Avoid Layout Groups in hot areas.
Horizontal/Vertical Layout Groups and Content Size Fitters are convenient, but they can trigger expensive layout recalculations. I still use them, just not inside fast-updating UI like scrolling lists that refresh every frame.

If you have a big inventory grid, consider setting positions manually or using a more controlled layout approach.

Be careful with animated UI.
Animating RectTransform properties on lots of elements can cause constant rebuild work. Sometimes it’s fine. Sometimes it becomes a hidden tax.

My rule: animate fewer elements, or animate at a parent level when possible.

Raycasts: the other quiet cost

Ever notice UI feels sluggish when there’s a lot of buttons or graphic elements layered on top of each other?

Graphic raycasting can add overhead, especially if lots of UI elements have Raycast Target enabled by default.

Quick win:

• Turn off Raycast Target on images and text that never need clicks.

• Keep interactive elements interactive. Everything else should be inert.

This is one of those changes that feels too small to matter… until it does.

A quick gut check for you

If you pause your game and just open a UI-heavy screen and your frame time jumps, that’s not “Unity being Unity.” That’s fixable.

UI optimization is boring work. Also some of the highest ROI work you can do.

Next, let’s talk about the part everyone expects to be the problem… the visuals. Lighting, shaders, and overdraw.

Lighting and shaders: yes, they matter. Just not how most people think.

This is the part where people expect the performance issue to be. And sometimes they’re right.

But I’ve noticed a pattern: a lot of Unity projects don’t run poorly because the visuals are “too high quality.” They run poorly because the visuals are messy. Too many real-time lights. Too many passes. Too much transparency. Too many effects stacked because they look cool in the Editor.

Cool in the Editor is not the same as stable on a mid-range laptop.

Real-time lighting is expensive, and it’s easy to overuse

If you have multiple real-time lights hitting lots of objects, Unity has to do extra work per pixel. Shadows make it worse. Spot lights can be surprisingly heavy. Point lights can be brutal if they overlap.

The practical approach that works in most games:

• Use baked lighting for anything that doesn’t move

• Keep real-time lights for a small number of important things

• Be picky about shadows and their resolution, distance, and count

And yeah, baking can be annoying. Lighting bakes fail, take ages, or need rebakes after small changes. Still worth it when you want consistent performance.

Shaders are often guilty by association

Shaders get blamed a lot because they sound scary. But the real issue is usually not “a shader,” it’s too many shader variants or too many features turned on at once.

Common examples:

• A material with keywords enabled for features you aren’t even using

• Multiple materials that are basically the same but not identical, so Unity can’t batch them

• Fancy surface shaders or graphs used everywhere, including tiny background props that could be cheap

If you’re using Shader Graph, keep an eye on how easy it is to build something that looks great but does a lot of work per pixel. Especially if it’s used on big surfaces.

Transparency and overdraw: the silent FPS drain

If there’s one visual issue I wish more Unity devs understood, it’s overdraw.

Overdraw happens when the GPU draws pixels… then draws over them again… and again… because transparent objects can’t be depth-culled the same way opaque ones can.

Particle systems, fog planes, glass, UI elements, foliage with alpha textures. Stack enough of those and you can melt a GPU while the scene still looks “simple.”

A few practical tips that actually help:

• Prefer cutout (alpha clip) over full transparency when possible

• Limit full-screen effects like heavy bloom, SSAO, depth of field, motion blur

• Don’t use “pretty particles” everywhere. Use them where they matter

Counterpoint: sometimes your visuals are fine

If the Profiler shows you’re CPU-bound, you can spend days optimizing lighting and not feel any improvement. This is why profiling first is non-negotiable.

But if your GPU time is high and you see heavy rendering cost, lighting and overdraw are usually where the real wins are.

Next up: the part that looks like a content problem but is usually a pipeline problem.

Your meshes, textures, and “why is this tiny prop 4K.”

If you’re working on heavier scenes or testing across different setups, tools like Unity Render Streaming can also help you run and interact with your project remotely without relying entirely on your local machine. You can check out how it works here.

Your assets are heavier than they look

Here’s a fun one.

You import a small prop. Maybe a plant. Maybe a rock. Looks harmless.

Then you check the stats later and realize… it’s 4,000 triangles and using a 4K texture.

And you’ve placed it 200 times.

I’ve seen this exact thing happen in real projects. More than once.

The problem isn’t one asset. It’s repetition.

A single high-poly model usually won’t kill your performance. But games are built on repetition.

That one rock? It’s everywhere. That one prop? Duplicated across the whole level.

So the real question isn’t “is this asset heavy?”
It’s “what happens when I use this 100 times?”

LODs are not optional if you care about performance

Level of Detail (LOD) systems let you swap models based on distance.

• Close → high detail

• Mid → medium

• Far → very low

Without LODs, you’re rendering full-detail meshes even when the player can barely see them.

That’s just wasted work.

Unity makes LOD Groups pretty easy to set up, and they pay off quickly in large scenes. Especially open environments.

Geometry vs textures: pick your battles

Sometimes devs try to “optimize” by reducing polygons but forget textures are just as important.

A few rules I stick to:

• Don’t use 4K textures unless the player is really going to notice

• Reuse textures and materials whenever possible

• Use normal maps to fake detail instead of adding more geometry

In a lot of cases, you can make something look detailed without actually being heavy. That’s the sweet spot.

Import settings matter more than you think

Unity’s default import settings are… fine. Not great.

Check these:

• Mesh compression (can reduce memory with minimal visual loss)

• Read/Write enabled (turn it off if you don’t need it)

• Texture compression formats (especially important on mobile)

• Mipmaps (usually yes, but depends on use case)

Small changes here don’t feel exciting, but across dozens or hundreds of assets, they add up.

When not to over-optimize assets

If your game is small, your scenes are simple, and your performance is already stable, you don’t need to aggressively reduce every mesh.

I’ve seen people destroy visual quality chasing “perfect optimization” that didn’t even move the frame rate.

Again, check the Profiler. If rendering isn’t your bottleneck, this might not be where your time should go.

But if it is, asset weight and repetition are usually where the biggest wins hide.

Next, let’s talk about something that feels like a design choice but ends up being a performance problem.

Your scene is doing too much… even when the player can’t see it.

Your scene is doing work the player never sees

Here’s something that took me a while to fully appreciate.

Just because something exists in your scene doesn’t mean it should be rendered.

Sounds obvious. It isn’t.

By default, Unity will try to render everything inside the camera’s view. And even then, it might still be doing more work than necessary depending on how your scene is structured.

So you end up paying for things the player isn’t even aware of.

Frustum culling is already helping you… but it’s not enough

Unity automatically avoids rendering objects outside the camera’s view. That’s called frustum culling.

Good. Necessary. Not sufficient.

Because what about objects that are technically in front of the camera… but completely blocked by a wall?

Unity doesn’t always skip those by default.

So yes, that entire building behind another building might still be processed.

Occlusion culling is where things get interesting

Occlusion culling tells Unity:

“If the player can’t see it, don’t render it.”

This can make a huge difference in:

• Indoor levels

• Dense urban scenes

• Complex environments with lots of blocking geometry

I’ve seen scenes where enabling occlusion culling noticeably reduced rendering cost just by preventing hidden objects from being processed.

But it’s not magic.

When occlusion culling helps… and when it doesn’t

It works best when your scene has clear visual blockers. Walls, terrain, large structures.

It doesn’t help much in:

• Open worlds with long sightlines

• Sparse scenes

• Very small environments

And it comes with a cost. Baking occlusion data takes time and memory. Sometimes the setup effort isn’t worth it for smaller projects.

The bigger idea: be intentional with what stays active

Culling is one layer. You can go further.

Ask yourself:

• Do distant enemies really need full AI updates?

• Do off-screen particle systems need to keep running?

• Do background objects need animations when no one sees them?

A lot of systems keep running simply because we never told them to stop.

Simple tricks that go a long way:

• Disable components based on distance

• Use trigger zones to activate/deactivate areas

• Stream parts of your scene instead of keeping everything loaded

This is where performance starts blending into game design.

Because at some point, optimization isn’t just about making things faster. It’s about deciding what actually deserves to exist at any given moment.

Next, let’s zoom out a bit.

Because optimization doesn’t look the same depending on where your game runs.

Optimization isn’t the same on every platform

A scene that runs perfectly on your PC can completely fall apart on a phone. Or in a WebGL build. Or in VR.

Same project. Very different results.

I think this is where a lot of Unity devs get blindsided. You build and test on your own machine, things feel fine, and then you try it on target hardware and suddenly everything is struggling.

Mobile: everything is tighter

On mobile, your budget is just smaller. Less CPU, less GPU power, less memory, stricter thermal limits.

Things that are “fine” on desktop become problems fast:

• Too many draw calls

• Heavy shaders

• High-resolution textures

• Garbage collection spikes

Even UI can hit harder here.

You also have to think about battery and heat. A game that pushes the device too hard might start throttling after a few minutes, which means performance gets worse over time. That’s a fun surprise if you’re not testing for it.

And if you’re experimenting with mobile workflows or testing Unity projects on tablets, there are actually ways to run Unity outside of a traditional desktop setup.

WebGL: different kind of pain

Web builds come with their own quirks.

• Memory is limited and more fragile

• Load times matter a lot more

• Garbage collection can feel more noticeable

• Debugging performance issues is… not always fun

You don’t get the same level of control or consistency as native builds, so you have to be extra careful with allocations and asset sizes.

VR: no room for spikes

VR is where things get strict.

You’re not just aiming for high FPS. You need stable frame timing. No spikes.

A small stutter on desktop might go unnoticed. In VR, it’s uncomfortable immediately.

That means:

• Aggressive optimization

• Lower draw calls

• Simpler shaders

• Careful CPU usage

You’re optimizing for consistency, not just raw performance.

PC and consoles: more power, higher expectations

Desktop gives you more headroom, sure. But it also raises expectations.

Players expect higher resolution, better lighting, more effects. So that extra power gets used quickly.

It’s easy to think “this runs fine on my machine” when your machine is stronger than your target audience’s.

A simple rule that saves headaches

Test early on your target platform. Not at the end.

If you wait until the final stages to check performance on mobile or WebGL, you’re going to end up rewriting things under pressure. That’s not fun.

Optimization isn’t a final step. It’s something that should guide decisions from the beginning, especially once you know where your game will run.

And this leads to a more practical problem most teams run into eventually.

Even if you know what to fix… actually testing and iterating on performance can be slow.

Performance is a design decision, not a final step

Here’s the shift that makes everything easier.

Performance isn’t something you “fix later.” It’s shaped by the decisions you make while building. How you structure scenes, how often things update, how you handle assets, what you choose to render. All of that adds up long before you ever open the Profiler for a serious pass.

And in practice, this is where things get tricky.

Because even if you understand all of this, your workflow can still slow you down. Heavy scenes take longer to run. Profiling gets messy when your machine is struggling. Testing different scenarios becomes something you avoid instead of something you iterate on.

That’s where tools like Vagon Cloud Computer start to make sense.

Not as a shortcut. Not as a fix for bad decisions. But as a way to remove friction from the process.

If you can run your Unity project on a stronger machine without worrying about your local hardware, a few things change:

• You can test complex scenes without your Editor crawling

• Profiling becomes clearer and more reliable

• You spend less time waiting and more time adjusting

• Sharing builds or environments with others becomes simpler

It doesn’t replace optimization. It just makes it easier to do properly.

And that ties back to the main idea.

If performance is part of how you design and iterate, not something you patch at the end, you end up with a smoother game and a much less painful development process.

Of course, having the right hardware still makes a difference. If you’re building or upgrading your setup, it’s worth understanding what actually matters for Unity performance.

Final thoughts

Most Unity performance problems aren’t mysterious. They just feel that way when you’re guessing.

Once you start profiling, patterns show up fast. You realize it’s rarely that one “heavy” effect you suspected. It’s usually a mix of small things stacking up. A few extra draw calls here, some unnecessary Update() calls there, a bit of UI overhead, a few allocations you didn’t notice.

None of these are hard to fix on their own. The challenge is seeing them clearly and fixing them early enough.

You don’t need perfect numbers. You don’t need to chase every millisecond. You just need to stay aware of what your game is doing under the hood and make decisions based on that.

And if there’s one practical takeaway from all of this, it’s this:

Performance gets easier when your workflow is smooth.

When you can test quickly, profile clearly, and run your scenes without your machine struggling, you make better decisions. That’s where something like Vagon Cloud Computer actually helps. Not by fixing your game for you, but by giving you a faster, more reliable environment to work in.

At the end of the day, good performance isn’t a trick. It’s a habit.

And once you build that habit, everything else gets a lot simpler.

If you’re stuck working on a lower-end machine, there are still ways to run Unity projects smoothly without a dedicated GPU.

FAQs

1. Do I really need to optimize early, or can I wait until the end?
You can wait, and a lot of people do. But it usually comes back to bite later. Small performance issues tend to pile up quietly, and by the time you notice them, they’re often tied into core systems. At that point, you’re not tweaking anymore, you’re rewriting. In my experience, just staying a little aware early on saves a lot of time later.

2. What’s the first thing I should check when my game slows down?
Open the Profiler. Always. The first thing you want to understand is whether you’re CPU-bound or GPU-bound. That one distinction clears up a lot of confusion. If the CPU is the issue, it’s usually scripts, physics, or too many objects being processed. If it’s the GPU, then you’re looking at rendering, lighting, shaders, or overdraw. Anything before that is basically guessing.

3. How many draw calls is “too many”?
There isn’t a single number that works for every project. On a desktop, a few thousand might be fine. On mobile, a few hundred can already cause problems. What actually matters is how those draw calls affect your frame time. If your CPU is struggling and you see a high batch count, it’s worth looking into. If your game runs smoothly, chasing lower numbers just for the sake of it doesn’t help much.

4. Is object pooling always necessary?
Not really. If you’re only spawning a few objects occasionally, you probably won’t notice much difference. But if you’re constantly creating and destroying things like bullets, enemies, or effects, pooling can make a big impact. It’s one of those tools you bring in when the problem shows up, not something you need everywhere by default.

5. Why does my game run fine in the Editor but not in a build?
The Editor adds overhead, sometimes more than people expect. That means performance there isn’t always reliable. It can look worse than it really is, or occasionally hide issues that show up in a build. If something is close to your limits, you really need to test in a build to get a clear answer.

6. Do I need to optimize UI separately?
Yes, and this is something many people overlook. Unity’s UI system can get expensive, especially when you have large Canvases, layout components, or elements that update frequently. If you notice spikes when interacting with UI, it’s usually a sign that something there needs attention, not just your gameplay systems.

7. Will using better hardware fix my performance issues?
No, it won’t fix them. But it will change how you work. Better hardware makes it easier to run your scenes, profile properly, and test without constant slowdowns. That’s where something like Vagon Cloud Computer comes in. It gives you access to stronger machines so you can actually iterate faster and see what’s going on more clearly. It doesn’t replace optimization, but it makes the whole process smoother.

8. What’s the biggest mistake people make with Unity performance?
Guessing. Turning random things off, tweaking settings without knowing the cause, hoping something sticks. It feels like progress, but most of the time it isn’t. The biggest improvement usually comes from one simple habit: check the Profiler first, then act.