I went ahead and put together a very simple test appllication that proves
what I am seeing when it comes to the EVL heap performance being
substantially slower than the Linux STL Heap. In the app, there are 2
pthreads that are attached to EVL and started one after the other. Each
thread creates/destroys 100k std::strings (which use new/delete behind the
scenes). The total thread time is calcluated and printed to the console
before the app shutsdown. If enabling the EVL heap, the global new/delete is
overridden to use the EVL Heap API.

Scenario 1 is an EVL application using the STL Heap. Build with the
following command: " g++ -Wall -g -std=c++11 -o test test.cpp
-I/opt/evl/include -L/opt/evl/lib -levl -lpthread". When this app is run on
my x86 system, I can see that the average time for the 2 threads to complete
is about 0.01 seconds.

Scenario 2 is an EVL application using the EVL Heap. Build with the
following command: " g++ -Wall -g -std=c++11 -o test test.cpp
-I/opt/evl/include -L/opt/evl/lib -levl -lpthread -D EVL_HEAP". When this
app is run on my x86 system, I can see that the average time for the 2
threads to complete is about 0.8 seconds.

This is a very simple example, but even here we can see that there is a
significant slow down using the EVL heap. That is only magnified when
running our much more complex application.

Is this expected behavior out of the EVL heap? If so, is using multiple EVL
heaps the recommendation? If not, where do we think the problem lies?


Thanks,

Russell