Investigate bad performance

[McGittyHub]

I'm drawing 12 different textures each having 64x64 pixels and being drawn upscaled by 4. This small scenario is maxing out one of my cpu cores and making it lag.. I don't know what is to blame or how to go about investigating this performance issue, I certainly wouldn't expect this simple scenario to be so heavy and sluggish on my 8700k. This is running on windows on a release mode build.

[17cupsofcoffee]

That's very strange - this definitely isn't expected behaviour, and I've not run into similar issues on my machine. Are you able to show your code, or a piece of code that replicates the issue?

[McGittyHub]

hmm, I don't know how to go about this.. I'll try to explain what my program is currently doing and where the performance issues arises. I stream in a 2d world of chunks/texture with res 64x64. I use mpsc and 1 thread to generate the chunks using perlin noise. One at a time. I understand that creating the texture is a heavy operation and thus the program stutters a little on every chunk load. That is okay and something I have to optimize with pooling. My performance problem is just rendering the 12 tiles that are in view. 1 cpu core is maxed out and I wouldn't expect that for only 12 sprites.

[17cupsofcoffee]

That's extremely weird 😬 I'll have to do some experimenting locally.

My performance problem is just rendering the 12 tiles that are in view.

Are you rendering more tiles that aren't in view? Tetra (currently...) doesn't do any culling for you, so if you're drawing a ton of sprites offscreen that could potentially account for the performance dip - although I still wouldn't expect a core to be maxed out because of that...

[McGittyHub]

nope, I'm only rendering 12 64x64 sprites that are procedurally generated

[McGittyHub]

I'm closing now, seems to be resolved when I added more stuff, or it was simply due to task manager reporting bad info.

[17cupsofcoffee]

Aha, no problem, glad you were able to fix it (and even more glad there's not some hidden bottleneck lurking in my code 😛).

If you want more reliable profiling data for cases where you think you might be CPU-bound, I've had pretty good results using VS2019's profiler or NVIDIA Nsight Systems to investigate. If you add this to your Cargo.toml, you'll get proper debug symbols in the profiler:

[profile.release]
debug = true

[McGittyHub]

Thanks for the tip! I have used vs for profiling before and liked it, don't feel like installing it again though since vs is so heavy :p