I have never taken off or changed optimizations under release mode. I changed around all of my shader stuff and went from lighting to deferred lighting with multiple render targets. My FPS went from around 1000 to 10. When I profile in debug mode I waste almost ALL my time inside of std::vector. This is understandable because its not optimized. BUT, when I switch to my release mode I get exactly the same FPS? Why is this? It should go up dramatically anyway you look at it... So... Questions are, What could be the issue? And most of all what switches need to be on to make std::vector optimized? Thanks, Brad. EDIT: I also use Visual C++ with microsofts compiler.

When I profile in debug mode I waste almost ALL my time inside of std::vector.

Where in std::vector ?

Quote:Original post by snk_kid
Well for one thing its definitely not std::vector being slow, that is way to dramatic to be the case.

The most likely case is your usage and not using it effectively, by the sound of things your probably doing loads of de/allocations & constructing/destroying in tight loops or every frame.

Where are you creating them? do you know about & how to use "reserve" method? you know it will be destroyed automatically by scope (assuming its not allocated on the heap itself).

You know std::vector separates de/allocation & construction/destruction that actually gives you an edge, its also parameterized by allocator type you can use custom allocators such as boost::pool_allocator with it.

Yea I know about reserve and trust me it does not work well with what im using. It works much better by dynamically letting it go. And I am not allocating, deallocating at all. I do when I load a map in, then deallocate when I end the map. The only allocating and deallocating belong to when I run my quadtree on some pointers. Thats it, and that was already tested and runs very fast. Meaning it wasnt at fault there. Thanks for hte response though...

Quote:Original post by Fruny
When I profile in debug mode I waste almost ALL my time inside of std::vector.

Where in std::vector ?

inside of "[]" This is in debug mode though. Debug is ALWAYS slow for me during std::vector. But it is always different in Release mode, ALOT different. Before all the new rewrites I recieved from 7fps in debug, to 1200fps in release.

I am also using VC++2003

And in release mode? operator[] should then be inlined, so you're certainly not going to spend much time there.

Quote:Original post by Fruny
And in release mode? operator[] should then be inlined, so you're certainly not going to spend much time there.

Right, that was what I assumed... I wish there was a way to profile it under Release mode. But for some reason I think it might not be optimizing. I dont know the exact flag though. Also, under profiling I couldnt find anything that would be making this problem? I mean its only like 700 triangles per frame, at 7 frames/sec... resulting in 4900triangles/second. This is absolute crap, something big is blocking this.

EDIT: I took out the SetRenderTarget( 0 through 3 ); nad the fps tripled... thats a start i guess...

[Edited by - xsirxx on June 6, 2005 7:53:31 PM]

you realise you havnt actually told us anything usfull to find the problem
apart from "std::vector is slow in debug, and i profiled it and [] is supposed
to be the slow point"

for all we know, you could be iterating through the vector 100000 time perframe
in which case its not std::vector, its your algorithm.

so, information that might help pinpoint the problem:

where is the most frequent use of the vector (access wise at least)

what is the vector holding (primivitves/pointers, structs, classes?)

how is vector being used (eg how in post processing/rendering)

a code fragment with some general layout of code usage, pseudo or otherwise

also, you switched to defered rendering, what is your hardware? it may seem to
be an unrelated issue, but system specs etc can sometimes be helpful.

Cheers
-Danu

Quote:Original post by silvermace
you realise you havnt actually told us anything usfull to find the problem
apart from "std::vector is slow in debug, and i profiled it and [] is supposed
to be the slow point"

for all we know, you could be iterating through the vector 100000 time perframe
in which case its not std::vector, its your algorithm.

so, information that might help pinpoint the problem:

where is the most frequent use of the vector (access wise at least)

what is the vector holding (primivitves/pointers, structs, classes?)

how is vector being used (eg how in post processing/rendering)

a code fragment with some general layout of code usage, pseudo or otherwise

also, you switched to defered rendering, what is your hardware? it may seem to
be an unrelated issue, but system specs etc can sometimes be helpful.

Cheers
-Danu

Well Im not iterating a vector 100000 times. I guess I have not made my point here. "[]" and anythign else in std::vector will be slow when ran in true debug mode. It should also be a HELL OF ALOT faster in release mode. I am seeing no improvement when I switch to release now. Which leads me to believe that somehow a switch got flipped. And I dont know which argument microsoft's compiler needs to turn it back on or to test if that is the problem.

Now code wise....

I have an EffectManager, which holds 4 lists, one which is a LPDIRECT3DPIXELSHADER, one is LPDIRECT3DVERTEXSHADER9, one a LPD3DXCONSTANTTABLE, and the other is a effect structure I have that holds various values needed, as far as handles to the Constants, and indecies to each pixelshader and vertex shader it needs. These shaders are created at the start of the map loading process and are created using fragments(why I dont use directx's effects). I cant see why this would help any though. Maybe thats why I cant seem to find the slow down even with profiling.

EDIT: I am testing on an AMD64, and 2 Geforce 6600gts in SLI, outside of SLI mode(for dual monitors), and 1gig of 2.5ns ram.

Also, The lists are being used by [], So When I load a material or a light, it accesses the EffectManager, and that in turn chooses the correct shader and constants. I pass into the effect manager the correct pointers to the new matrices to use.

[Edited by - xsirxx on June 6, 2005 8:03:23 PM]