简体   繁体   中英

Why vector allocation take so much time even with optimization level 3?

Previously I asked this similar question here

Android NDK: vector.resize() is too slow, related to allocation?

Issue was that this code

#include <chrono>
#include <android/log.h>
#include <vector>

while (true)
    {
        const int sz = 2048*2048*3;
        std::vector<unsigned char> v;
        {
            auto startTime = std::chrono::system_clock::now();
            v.resize(sz);
            auto duration = std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::system_clock::now() - startTime);
            __android_log_print(ANDROID_LOG_ERROR, "READFILE 1", "v.resize(%d) time : %lld\n", sz, duration.count());
        }
        {
            auto startTime = std::chrono::system_clock::now();
            v.resize(0);
            auto duration = std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::system_clock::now() - startTime);
            __android_log_print(ANDROID_LOG_ERROR, "READFILE 2", "v.resize(0) time : %lld\n", duration.count());
        }
        {
            auto startTime = std::chrono::system_clock::now();
            v.resize(sz);
            auto duration = std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::system_clock::now() - startTime);
            __android_log_print(ANDROID_LOG_ERROR, "READFILE 3", "v.resize(%d) time : %lld\n", sz, duration.count());
        }
    }

Took me aroud 500 milliseconds (look at question that I liked above)

34.4171: v.resize(12582912) time : 845977
34.9682: v.resize(0) time : 550995
35.5293: v.resize(12582912) time : 561165
36.6121: v.resize(12582912) time : 530845
37.1612: v.resize(0) time : 548528
37.7183: v.resize(12582912) time : 556559
38.7811: v.resize(12582912) time : 515162
39.3312: v.resize(0) time : 550630
39.8883: v.resize(12582912) time : 556319
40.9711: v.resize(12582912) time : 530739
41.5182: v.resize(0) time : 546654
42.0733: v.resize(12582912) time : 554924
43.1321: v.resize(12582912) time : 511659
43.6802: v.resize(0) time : 547084
44.2373: v.resize(12582912) time : 557001
45.3201: v.resize(12582912) time : 530313

and with help of @Snild Dolkow I succesfully dicline this time to 4 milliseconds

E/READFILE 1: v.resize(12582912) time : 573
E/READFILE 2: v.resize(0) time : 0
E/READFILE 3: v.resize(12582912) time : 4683
E/READFILE 1: v.resize(12582912) time : 557
E/READFILE 2: v.resize(0) time : 0
E/READFILE 3: v.resize(12582912) time : 4680
E/READFILE 1: v.resize(12582912) time : 552
E/READFILE 2: v.resize(0) time : 0
E/READFILE 3: v.resize(12582912) time : 4683

I just added this lines in my CMakeList.txt file

target_compile_options(native-lib PRIVATE
    "$<$<CONFIG:RELEASE>:-O3>"
    "$<$<CONFIG:DEBUG>:-O3>")

But I realized that anyway the time that you can see in a second log, is now really logical... Something weird is going on here.

Take a look - first allocation take 552 microseconds, then resize to 0 take 0 milliseconds(it is ok), but last resize that is actually resize to the same size that was in first resize take 4600 microseconds.

It is could not be possible because the vector have already was resized and only value that changing when I call resize to 0 is acctually count of elements inside, so call again resize to number that was before it is means just change the count inside the vector implementation, in other words it should take not more that 0 microseconds...

So, question is - is it really ndk bug? Or, I miss something here?

You're missing that std::vector<T>::resize(N, T defaultVal=T{}) sets all N values to defaultVal . If you don't specify a default value, the default is T{} . In your case, that's zero.

The method which only does allocation, and does not affect values is called std::vector::reserve(N) . Related functions are std::vector::capacity() and std::vector::shrink_to_fit()

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM