Re: Who can provide me some help on how to eliminate delay and speed up the setup process.
From: Nick Landsberg (SPAMhukolauTRAP_at_SPAMworldnetTRAP.att.net)
Date: 08/31/04
- Next message: Ben Measures: "Re: c++ becoming outdated? c# the next 'in' thing?"
- Previous message: Jason: "Re: i hate JAVA"
- In reply to: David: "Re: Who can provide me some help on how to eliminate delay and speed up the setup process."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 30 Aug 2004 22:30:12 GMT
David wrote:
> On Mon, 30 Aug 2004 12:59:29 UTC, "Xiangliang Meng"
> <xiangliang_meng@hotmail.com> wrote:
>
>
>>Hi, all.
>>
>>An urgent and hot issues is working in my hand.
>>
>>After many months pass by, a lot of code changes have made. Suddenly, they
>>find our system become slower a little during the setup process, so we must
>>find some ways to speed it up.
>>
>>According to our observation, the delay is not limited in a single function,
>>but it is an accumulated result of many functions in many files. Therefore,
>>it is hard for me to find out the exact places causing such delay. It seems
>>impossible for me to find the statments and leaf functions causing the delay
>>very much.
>>
>>What can I do for this? Find out the suspect places and try to accelerate
>>them as possible as I can? Or try to quicken any place where I can do some
>>improvement? Will we do as good as or better than before? I'm not sure which
>>kinds of approaches is better for me now and whether we could achieve.
>>
>>Who can provide me help on how to eliminate delay and speed up the setup
>>process? Any adivce is welcome. Thanks a lot.
>>
>>Best Regards,
>>
>>Xiangliang Meng
>
>
> What exactly is the customer complaining about? Is this a perceived
> slowdown or a measurable one?
>
> I've often found that starting a monolithic application appears slow
> to a user, even if the application is fully usable once it appears.
> Staging the application start can reduce the perceived problem. That is,
> show the the GUI or other interfaces are starting up even before the
> rest of the core system is ready to operate. This is helpful when the
> customer is just watching the system and really isn't ready to use the
> system once it is started. Microsoft's OSes take a similar approach.
> They present the Ctl+Alt+Del display and appear to be ready, but
> performing that step may eventually bring up the users environment only
> to have them finding that the shell is still 'starting in the background'
> and the UI isn't really paying attention yet.
>
> As for the changes you have made, ca you identify what they were and
> look at them? There are a multitude of guidelines for any given language
> or OS that might help you tune the system. Of course, its also possible
> that your changes require more start-up time.
>
> Certainly a profiling tool, or even a good log with timestamps, can
> help you identify what parts of the system are taking a while to start
> up. Just optimizing everything won't gaurantee you'll find the problem
> they are complaining about. Take some time and try to measure the
> start-up times of the various portions of the system. This works best
> if you can compare it with the old system. Also remember that when
> multiple tasks are operating there may be some uncertainty in the
> start up times. 2.0 seconds may look slow, but does it take 0.5 seconds
> the next time? If so there is probably something else going on. This
> also means that it can be very hard to measure improvements as the
> behavior may not be consistant.
>
> We may be able to help if more details are provided.
>
> David
All good points David. However what caught my eye was
VxWorks in a subsequent followup by the OP.
That's a "real-time" OS where the application more-or-less
has control of the scheduling and is almost exclusively
used in embedded systems.
To the OP:
If it is just a startup problem, I would first look at the
size of the file(s) being read in at startup. If you
were reading in X MB and are now reading in X+Y MB,
you will be slower. There may be a way of optimizing
the disk reads with a disk re-org.
Secondly, I would look at your locking/mutex strategy
especially with regards to the granularity of the
locks. If you're locking out another task while
some disk read is going on (and it's not necessary
to do so) then there may be room for improvement here.
Also, I would look not only at the routines/methods
that are used, but the frequency of invocation.
A "very fast" routine invoked a million times
will still slow you down.
In addition, I would look into memory-to-memory
copies of data and how they are handled and how
frequent they are during the startup phase.
Just my ramblings.
NPL
-- "It is impossible to make anything foolproof because fools are so ingenious" - A. Bloch
- Next message: Ben Measures: "Re: c++ becoming outdated? c# the next 'in' thing?"
- Previous message: Jason: "Re: i hate JAVA"
- In reply to: David: "Re: Who can provide me some help on how to eliminate delay and speed up the setup process."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
