Hey i have a questen regarding the assimp performance in debug mode.
I have compiled assimp with dynamic_debug_dll and dynamic_release_dll configuration. When i compile my own project in debug mode i use also the assimp debug dll. But the loading performance is very low and i have two wait several minutes even for a small asset. When i want to use the release_dll in debug mode i get a access violation.
Is there a workaround or what i am doing wrong?
Thank you and greets
tosken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure if you're doing anything wrong. Debug build is of course much slower than release build, up to 20x slower in my experience. But that's normal. But I don't know of any file that needs minutes to read, especially not "small" assets. It's maybe the DLL build that causes this slowdowns, I can't tell for sure. I only ever used the statically linked versions.
Do you have a certain file in mind that needs that long? If yes and the license allows it, please post a link to it so that we can check for ourselfs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that problem in release builds is most likely caused by the wrong runtime. Please try 'multithreaded (debug) dll' or - better - take the current SVN version, it uses multithreaded dll by default.
Regarding debug performance: it's the fault of the Microsoft STL and its incredibly slow runtime checks. A good workaround is to compile against STLport, I tested it a few days ago and it was considerably faster in debug builds (especially for vc9).
gjaegy has proposed to define _SECURE_SCL=0 in the preprocessor options, that should fix your performance problems. I've added it to the vc9 solution of the current SVN version (do a full rebuild of everything, even cppunit if you want the unittests), so please give it a try. Debug builds will never be fast, but I fully agree that 2 minutes are too long for a medium-sized model :-)
Please give feedback if this works for you, thanks.
Bye,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in the case some STL containers are used as parameter in Assimp API (i.e. STL containers are use to transfer data between Assimp and the host application), make sure this preprocessor definition is well documented.
If the library and the application don't define this definition the same way, a crash will occur...
Just as a warning ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeah, thanks for the warning, I think I see the problem :-)
Importer::GetExtensionList() is afaik the only case where a STL container is transfered to the application. I''ll replace that with an aiString instead.
Bye,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not completely sure std:string is concerned as well; I know std::vector, deque, etc... are. So I guess string are as well...
In any case, removing STL from the public interface is a good thing to make sure these kind of things don't happen.
And thanks a lot for your work and support: it's just great ;) Glad I can help (even if only a little bit) ! I really hope assimp will become a popular and widely-used library (as this would mean the library would have a long life ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey i have a questen regarding the assimp performance in debug mode.
I have compiled assimp with dynamic_debug_dll and dynamic_release_dll configuration. When i compile my own project in debug mode i use also the assimp debug dll. But the loading performance is very low and i have two wait several minutes even for a small asset. When i want to use the release_dll in debug mode i get a access violation.
Is there a workaround or what i am doing wrong?
Thank you and greets
tosken
I'm not sure if you're doing anything wrong. Debug build is of course much slower than release build, up to 20x slower in my experience. But that's normal. But I don't know of any file that needs minutes to read, especially not "small" assets. It's maybe the DLL build that causes this slowdowns, I can't tell for sure. I only ever used the statically linked versions.
Do you have a certain file in mind that needs that long? If yes and the license allows it, please post a link to it so that we can check for ourselfs.
Hi,
that problem in release builds is most likely caused by the wrong runtime. Please try 'multithreaded (debug) dll' or - better - take the current SVN version, it uses multithreaded dll by default.
Regarding debug performance: it's the fault of the Microsoft STL and its incredibly slow runtime checks. A good workaround is to compile against STLport, I tested it a few days ago and it was considerably faster in debug builds (especially for vc9).
gjaegy has proposed to define _SECURE_SCL=0 in the preprocessor options, that should fix your performance problems. I've added it to the vc9 solution of the current SVN version (do a full rebuild of everything, even cppunit if you want the unittests), so please give it a try. Debug builds will never be fast, but I fully agree that 2 minutes are too long for a medium-sized model :-)
Please give feedback if this works for you, thanks.
Bye,
Alex
Alex,
in the case some STL containers are used as parameter in Assimp API (i.e. STL containers are use to transfer data between Assimp and the host application), make sure this preprocessor definition is well documented.
If the library and the application don't define this definition the same way, a crash will occur...
Just as a warning ;)
Jeah, thanks for the warning, I think I see the problem :-)
Importer::GetExtensionList() is afaik the only case where a STL container is transfered to the application. I''ll replace that with an aiString instead.
Bye,
Alex
Hmm, I forgot that even Importer::ReadFile() takes a std::string.
It is probably the best choice to remove *all* STL occurences from the public API. An additional section in the docs is appropriate, too.
Thanks for your hints, Gregory!
Alex
Not completely sure std:string is concerned as well; I know std::vector, deque, etc... are. So I guess string are as well...
In any case, removing STL from the public interface is a good thing to make sure these kind of things don't happen.
And thanks a lot for your work and support: it's just great ;) Glad I can help (even if only a little bit) ! I really hope assimp will become a popular and widely-used library (as this would mean the library would have a long life ;)