Performance: VC++ 33% slower then Builder 5 on LineTo() API call??

[Gustavo L. Fabro]

Greetings!

Getting straight to the point, here are the results
of my experiment. I've included my comments and questions
after them.

The timing:
(The total time means the sum of each line's drawing time.
Time is measured in clock ticks (from QueryPerformanc eCounter() API).
The processor resolution (QueryPerforman ceFrequency()) for my
machine is 3579545).
------------------------------------------
Visual Studio .NET 2003
Total time: 717230
Average: 89.8165625

Borland Builder 5:
Total Time: 482151
Average: 61.0975

The code (for the DLL):
------------------------------------------
DrawDll.h
#ifdef DRAWDLL_EXPORTS
#define DRAWDLL_API __declspec(dlle xport)
#else
#define DRAWDLL_API __declspec(dlli mport)
#endif

class DRAWDLL_API CDrawDll {
public:
CDrawDll(void);
void MyMethod(HWND handle);
};

DrawDll.cpp
#include "stdafx.h"
#include "DrawDll.h"
#include <stdio.h>

BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_c all,
LPVOID lpReserved
)
{
return TRUE;
}

void CDrawDll::MyMet hod(HWND handle)
{

HDC hDC = ::GetDC(handle) ;

LARGE_INTEGER m_StartCounter; // start time
LARGE_INTEGER m_EndCounter; // finish time
__int64 m_ElapsedTime;
char buff2[255];

//For 800 different positions
for(int x=0;x<800;x++)
{
//10 times on each position
for(int rep=0;rep<10;re p++)
{
QueryPerformanc eCounter (&m_StartCounte r);

::MoveToEx(hDC, x,0, NULL);
::LineTo(hDC, 50+x,50);

QueryPerformanc eCounter (&m_EndCounter) ;

//get and store finishing time and calc elapsed time(ticks)
m_2ElapsedTime = (m_2EndCounter. QuadPart -
m_2StartCounter .QuadPart );
sprintf(buff2, "%d\n", m_2ElapsedTime) ;
OutputDebugStri ng(buff2);
}
}

ReleaseDC(handl e, hDC);

}

CDrawDll::CDraw Dll()
{
return;
}

The explanation
---------------------------------------------------------

In the translation process from a big project to Visual Studio, I started
facing some performance problems. Things were much slower on the VS compiled
executables. I went to study what exactly was happening and got to some
staring (to my point of view) conclusions.

I made a DLL and compiled it on Builder and Visual C++ .NET, with all
optimizations enabled for both compilers. The DLL has a class with only
one function, that gets a handle for a DC and draws 8.000 lines on it.

I made 2 executables that run the function from the DLL (compiled with
both compilers too).

The results were astonishing, for me, and I'd like an explanation for
what is happening.

I've run the test several times and the results are always of the
same magnitude. How can that be, if the only thing I'm doing is MoveTo() and
LineTo() API calls?

It's something simple! I'm not playing with the disk, loading large
chunks of memory, using managed extensions (I created a 'pure' Win32
project under VS), anything that could relate with performance.
Only 2 simple API calls.

Is Visual C++ really THAT MUCH slower?

I have the complete code and compiled executables here and will be glad
to send to anyone who wants to replicate the test. As for this posting
is concerned:

- Is VS compiled DLLs and/or executables inherently slower then, for
instance, Builder 5?
- Why does a simple API call takes that longer? Isn't it the same API call?
Shouldn't the call be fast and the API function itself take longer?
- Is there anything I can do/try to make the code run faster?

We would like to migrate other big projects for Visual C++, but now we're
having
second thoughts!

Waiting for a light,

Gustavo L. Fabro

[Gustavo L. Fabro]

> Just out of curiosity. How come you are not using hardware to render your

lines (i.e. DirectX). If performance is an issue, using DirectX to draw
lines
would give you a seemingly infinite boost in performance compared to
rendering your lines in software (even anti-aliased lines).
Hmmm... As far as I know (or knew), GDI calls are accelerated by hardware
when
available (and when the "Hardware Acceleration" slider in Control Panel,
Video, Configuration, Advanced, Problem Solving is not all to the left).

The profiling for the problem of this post, for instance, was made using
a computer with the "Hardware Acceleration" slider a couple of notches
to the left. It took an average of 270206 ticks to draw 8.000 lines. With
hardware acceleration fully enabled, the time droped to 62123.

Am I wrong? If DirectX could give an infinite boost in performance
I would definitely be interested!

Fabro
Just curious.

cheers,
Luis Miguel Huapaya

"Gustavo L. Fabro" wrote:

> Did you look at the assembly produced by both compilers?

By this time I unfortunately don't have the necessary knowledge in
assembly
language to be able to tell something concrete out of 2 given codes. If
that
helps I can disassemble both DLLs and post the code here!

>
> But artificial tests like this rarely mean anything in real
> applications...

I'm afraid this is not the case here. This test is just a replication of
something I have
seen in practice. Our CAD application took 5 times longer to draw the
same
file
in the screen with the VS compiled version then with our Builder compiled
one.

As the application itself has lots of classes, DLLs, and we used managed
and
unmanaged C++ in the middle, I tried to first check out if the API calls
themselves, after all the processing (of elements, points positions, etc)
were running at the same speed. In case that was true, I would then try
to
focus on the managed/unmanaged approach, DLL interaction and other
factors.

But when I saw that even the API drawing calls themselves were taking
longer, I got intrigued... And decided to do this test! Hence the results
here demonstrated and the question: Is it *really* like this?

Fabro

[Derrick Coetzee [MSFT]]

Gustavo L. Fabro wrote:

for(int rep=0;rep<10;re p++)
{
QueryPerformanc eCounter (&m_StartCounte r);

::MoveToEx(hDC, x,0, NULL);
::LineTo(hDC, 50+x,50);

QueryPerformanc eCounter (&m_EndCounter) ;

/* snip */
}
------------------------------------------
Visual Studio .NET 2003
Total time: 717230
Average: 89.8165625

Borland Builder 5:
Total Time: 482151
Average: 61.0975

I can't explain the speed difference in your experiment, but I can say
that if you are writing or porting an application for which drawing
primitives are a critical bottleneck, such as the CAD applications you
cite in a later post, you should seriously consider using a
performance-oriented graphics library such as DirectX or OpenGL, which
takes advantage of modern hardware. The GDI is, quite frankly, rarely up
to the task of serious graphics work, just simple business graphics such
as bar charts and buttons.
--
Derrick Coetzee, Microsoft Speech Server developer
This posting is provided "AS IS" with no warranties, and confers no
rights. Use of included code samples are subject to the terms
specified at http://www.microsoft.com/info/cpyright.htm

[Tom Widmer]

Gustavo L. Fabro wrote:

Just out of curiosity. How come you are not using hardware to render your
lines (i.e. DirectX). If performance is an issue, using DirectX to draw
lines
would give you a seemingly infinite boost in performance compared to
rendering your lines in software (even anti-aliased lines).

Hmmm... As far as I know (or knew), GDI calls are accelerated by hardware
when
available (and when the "Hardware Acceleration" slider in Control Panel,
Video, Configuration, Advanced, Problem Solving is not all to the left).

The profiling for the problem of this post, for instance, was made using
a computer with the "Hardware Acceleration" slider a couple of notches
to the left. It took an average of 270206 ticks to draw 8.000 lines. With
hardware acceleration fully enabled, the time droped to 62123.

Am I wrong? If DirectX could give an infinite boost in performance
I would definitely be interested!

Yes, such 2D calls generally are accelerated by hardware. However, for
the ultimate in speed, you should perhaps render using 3D hardware,
although this requires a lot of extra programming work. This would be
appropriate for a CAD application though, perhaps.

Tom