C++/VB - dll loading time performance

Asked By Frank-O

16-Feb-08 04:48 AM

Hi all,

I got a problem, I want to speed up the startup of my huge application
(100 dlls)
the loading of one particular dll (gred.dll) takes about 10sec. one my
of my colleague suggested to load that dll in a background thread at
startup.
Here's my action i have created a class CTaskThreads

// in the constructor
this->m_Thread = AfxBeginThread(WorkerThreadLauncher, this);

UINT CTaskThreads::WorkerThreadLauncher(LPVOID pvParam)
{
CTaskThreads *pThreadInstance =
reinterpret_cast<CTaskThreads *>(pvParam);
return pThreadInstance->Execute();
}

UINT CTaskThreads::Execute()
{

DWORD start = ::GetTickCount();

do
{
::Sleep( 1000 );
HINSTANCE hInstLib = ::LoadLibrary(_T("GRED.DLL"));
if ( hInstLib == NULL)
{
ASSERT(FALSE);
}

} while ( this->m_StopThread == false ) ;

DWORD end = ::GetTickCount();

this->ExecutionTime = end - start;

return 0;
}

Then in my executable module, initinstance() i have declare  a
CTaskThreads object.
unfortunately in some dll it failed to load some xml file ressources.

Since I am a beginner in this area i have a few questions regarding
this issue :

Why loading a dll takes time ? it depends on what ?
Is it a good idea to load a library the way i did ?
Is there a better solution ?
why it is imposible to load some ressources in some linked dll ?

thk u
Franck-o

14-Feb-08 04:34 AM

* Frank-O:

Reduce the number of DLLs drastically.

Consider splitting the single monlithic application into several programs.

For the rest, consider delay-loaded DLLs (directly supported by Visual C++).



You could check the dependencies, but since you're going to redesign
this thing anyway (aren't you?) there's not really much point in that.

Ditto for basing the DLLs (assigning preferred load addresses).



Uh.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

16-Feb-08 04:48 AM

).

Thx for your answer,
It seems ideal to redesign everything, but this is a very old
application i'll be too costly...for my boss

What's wrong with multithreading for that purpose ?

Frank-o

15-Feb-08 07:08 AM

Frank-O schrieb:


Before considerung solutions, you should analyse the problem.
The question is: Why does the DLL load so slow? Why do you think that multiple
threads would make loading faster?

When loading of a DLL takes a long time, it can be due to many reasons:
* The DLL is really huge, so the time is spent reading the hard disk.
* The DLL has a very complex DllMain that takes a long time to execute
* The DLL has many dependencies that need to be loaded as well.
* Windows needs to rebase the DLL
* The DllMain allocates a huge amount of memory so windows needs to re-arrange
its memory layout (trashing, paging)

There might be more reasons. But as long as the reason is not the busy CPU than
you won't gain much performance effect when loading the DLL in a separate
thread. All threads share the same hard disk, memory manager, process etc. And I
guess the main application still needs to wait until all DLLs have been loaded
before it can proceed.

What you actually can do is move the complete DLL loading funtion into a
separate thread. At least you can have the GUI responsive and the user gets the
feeling the application loads fast. You would still need to disable all commands
that rely on the not-yet-loaded DLLs.

Norbert

15-Feb-08 12:58 PM

In article <fae29983-14e4-48b9-aa92-30fcade87a6e@d4g2000prg.googlegroups.com>,



What's wrong? I'd say that it's wrong to blindly jump into a
solution without analyzing the problem first. Have you done any
benchmarks to see where the problem lies? Is the HD busy thrashing?
(Tip: make a ramdisk and load your app from that; I bet your boss's HD
wasn't been defragged in years.) Multithreading won't do a thing to
make your HD faster. If you're busy firing off HD access from multiple
threads, that can make things *slower* as your HD's read head
ping-pongs around. Sustained large sequential reads are better for
your HD than a lot of little ones all over the place. Alternatively,
is it the CPU that's busy? Multithreading may make the problem worse,
as that can pollute out your L2 cache.

time. However, debugging the last 10% can take a REALLY long time,
especially if this is a "very old application" that almost certainly
wasn't designed with multithreading in mind.

I really encourage you to try a profiler -- AMD's CodeAnalyst
is a free download and doesn't require an AMD CPU in the system:
http://developer.amd.com/tools/codeanalystwindows/Pages/default.aspx
Figure out the root of the problem. ***THEN*** implement a solution.

Nathan Mates
--

16-Feb-08 08:26 PM

I'll give you one example.  What if that DLL is creating GUI elements, like
windows?  Windows receive messages on the queue of the thread that created
them.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

17-Feb-08 10:20 AM

I have used Aqtime to analyse the application :
This particular DLL 's (Gred.dll ) size is 6MB and it also uses 15
medium-sized (3MB) static libraries.
Most of the time is spent loaded the dependents DLL , read records
from the huge data base, and drawing/creating the graphic user
interface components.


Yes the main application needs to wait until all DLLs have been
loaded, and disable all the commands that rely on it is simply not an
option since I am not even aware of the number of Commands that need
Gred.dll to be loaded dynamically.


My Ideas :
The DLL will not be loaded at startup instead it will be loaded the
first time a function is actually call.
I also started to optimize the code for reducing the load on the data
base...
since this a parameterized application, I will propose to enable the
user to select options to disable some tasks perform at start-up.

Concerning multithreaded issues :
-In a single processor architecture there will be no real gain in
time.
-It seeems that the DLLs are not thread safe

Could you explain your statement ?

Thx all

18-Feb-08 09:29 AM

Only if the process is performing independent I/O (i.e. over a network)
would a separate thread help.

However if the database access or dependent DLLs are loaded over a network,
then multithreading could give huge benefits by allowing multiple requests
to be sent at the same time.

18-Feb-08 11:12 PM

When you call CreateWindow, that window is "owned" by the thread that
created it, and messages for that window will be sent into the message
queue for that thread.  The normal message loop, which runs in the main
thread, will never see them.  In fact, if that second thread doesn't start
a message loop, the messages will never be processed.

That's why you read so many articles warning about combining GUI operations
with multithreading.

Now, if you know the DLL isn't going to create any windows, then it would
be fine to call it from a second thread.  I just presented one possible
counterexample.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

19-Feb-08 10:08 AM

Of course, since you are starting the second thread yourself and managing
the DLL load, running a message dispatch loop there is entirely possible.