- Forum
- General C++ Programming
- delete object take time
delete object take time
Hello folks,
I have a strange problem. While timing where the bottlenecks are in a big program I discovered that deleting an object took over 2 seconds!
Since the allocation, usage and freeing of the object is within a few lines in the program, I wrote a test program that did exactly the same. But in the test program it took 8 milliseconds to delete it.
What can cause the deleting of the object to take 2300 milliseconds in the other program?
The object I create has a set of input parameters in the constructor used to ask for data from a MySQL database and filling data into a std::deque object using a struct with three different values.
In both the program and the test program, the parameters are the same resulting in the same amount of data being loaded from the database.
I have a strange problem. While timing where the bottlenecks are in a big program I discovered that deleting an object took over 2 seconds!
Since the allocation, usage and freeing of the object is within a few lines in the program, I wrote a test program that did exactly the same. But in the test program it took 8 milliseconds to delete it.
What can cause the deleting of the object to take 2300 milliseconds in the other program?
The object I create has a set of input parameters in the constructor used to ask for data from a MySQL database and filling data into a std::deque object using a struct with three different values.
In both the program and the test program, the parameters are the same resulting in the same amount of data being loaded from the database.
What is more strange - I copied the testcode into the big program so it could be executed before the orignial code (which the test code was based on). Then the deletion of the object in both the test code and the original code within the program used less than 10 ms.
Even if I did a
if (false) {
... test code.
}
it worked fast in the orignal code. But when commenting out the code, it went back to using over 2300 milliseconds.
There must be a ghost in my code! Or can this be explained?
Even if I did a
if (false) {
... test code.
}
it worked fast in the orignal code. But when commenting out the code, it went back to using over 2300 milliseconds.
There must be a ghost in my code! Or can this be explained?
it could be explained. Depends... are you hitting virtual memory in the bigger program? Is it possible you have an issue with system resources?
I don't think it should be a memory problem. The program work fine and give the correct answer on the complex calculation (some of the calculation is done AFTER the point where the object deletion take so much time).
The system has 64 Gb physical memory and 40 Gb swap file. It's on a linux server:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
The system has 64 Gb physical memory and 40 Gb swap file. It's on a linux server:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
| I discovered that deleting an object took over 2 seconds! |
When an object is deleted, it's destructor is called. It's destructor may contain (almost) arbitrary code. Are you waiting for a long-running operation to complete in the destructor (e.g., waiting for
fsync() or something?)Remember that the destructors of sub-objects are called recursively.
Last edited on
I delayed the object deleting to the end of the function where the allocation take place. It seems to help - the deleting take much less time.
Compiler bug??
Compiler bug??
The class itself has an empty destructor. It has a forward_list, three map objects - one of them with a deque in it.
I also tried to free the data/objects in the forward_list and map myself in the destructor in the object and timed it - it took only a few milliseconds to perform. So I don't think the problem is with the destruction of the data itself but somewhere else.
I also tried to free the data/objects in the forward_list and map myself in the destructor in the object and timed it - it took only a few milliseconds to perform. So I don't think the problem is with the destruction of the data itself but somewhere else.
| There must be a ghost in my code! Or can this be explained? |
| I delayed the object deleting to the end of the function where the allocation take place. It seems to help - the deleting take much less time. |
Can you please post some code? What does your profiler say?
| Compiler bug?? |
Most likely not.
Is your system low on physical memory? If you can, you should measure the number of minor page faults that happen during the run of that code.
Remember, the linked data structures typically contain data is lots of different pages.
Remember, the linked data structures typically contain data is lots of different pages.
> Since the allocation, usage and freeing of the object is within a few lines in the program
> I delayed the object deleting to the end of the function where the allocation take place.
¿is the dynamic allocation necessary?
> I also tried to free the data/objects in the forward_list and map myself
¿ah? ¿what you mean?
> I delayed the object deleting to the end of the function where the allocation take place.
delete new T();¿is the dynamic allocation necessary?
> I also tried to free the data/objects in the forward_list and map myself
¿ah? ¿what you mean?
Topic archived. No new replies allowed.