yang686526

long time to load in linux
long time to load in linux
one of our customer files takes a few seconds to load and process on windows, but takes over 15 mintues on linux. most files are fine on linux, but some take over a minute and this one takes over 15 minutes. it is even this way using odreadex. is there something we can do to make the processing faster?
i could not upload the file to here, so please download it from
we can reproduce this, but we don't know what's causing it.
we'll look into it.
any progress?
this is still causing us grief on our linux implementation. we have several customers that will not buy our product until this is fixed.
we investigated this issue, and it seems that gcc produces much slower code than msvc. we found similar performance disparities between gcc and metrowerks codewarrior 9 on the mac, and between gcc and sun's c compiler on solaris.
changing the gcc optimization settings did not seem to have any significant effect on the overall speed.
we tried to use stlport instead of the gcc stl implementation, but it seems that stlport doesn't work with gcc 4.0, and we also tried it with gcc 3.4 and there were a lot of errors when trying to build our code.
we also tried intel's linux compiler, but it gave similar poor performance when using the gcc standard libs, and we had link problems when trying to use intel's standard libraries. if the intel compiler is an option for you, we can spend some more time trying to resolve the linker errors (but this will most likely have to wait until after the upcoming 1.15 release).
and finally we tried sun's linux c++ compiler--the binaries built by this compiler on linux gave very good performance. however, this compiler is still an alpha version, so it is probably not usable at this point.

did you do profiling to see if the catastrophic slowdown was specific to any areas of code (such as memory allocations, etc)? gcc does tend to be slower but it shouldn't be orders of magnitude slower.
we did some profiling using gprof, but there did not appear to be any single area that was causing the slowdown.

i think at least some of the problem is because gcc list<>::size() is o(n) instead of o(1).
would probably help to change things like
code:
if ( m_ids.size() )
to
code:
if ( !m_ids.empty() )
found using apple's amazing shark tool at
haven't tested it yet tho - just did a quick glance at it with shark.
thanks for the info--we will experiment with this and let you know the results.

that was the source of the slowdown--thank you!
the next 2.0 update will contain the fix for this.