Re: Performance issues on a CE-app that was ported from Win32
- From: "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
- Date: Tue, 16 Sep 2008 12:03:23 -0500
After mapping the processes more thoroughly I've counted that there are
actually a total of seven processes constantly running, with others
starting
up on request. Of the residual processes, only 4 play a major part when a
message is being received:
That's still too many, IMO. There's no reason this needs to be process
compartmentalized, and doing so requires context switching for the scheduler
to run the functions in each application.
handle an incoming message. I've tried monitoring what process might eat
up
the CPU cycles with the performance monitor, but the monitor doesn't seem
all
that accurate. I've set it up to monitor all of the seven processes, but
no
matter how many messages I send, even the total processor time for many of
the processes is still zero...now I know that is cannot be correct, so
either
the CPU time used by those processes are actually too small to register,
or
it doesn't get registered at all for some reason. Does anyone have any
suggestions for how I would go about monitoring the processes more
accurately?
The Remote Profiler would be good, as kernel tracker would definitely give
you a sense of who's doing what.
Regarding the IPC mechanism: all IPC-messages are actually received/sent
with ReadFile/WriteFile-calls to a driver. Now, this actually makes sense
in
the context of which it is used on the desktop version (you'll just have
to
trust me on this =), but the more I think about it, it's an absolutely
useless thing to do in the CE-version. None of the reasons that was valid
on
the desktop-version really applies here. So this is certainly a thing I'll
have to look more closely at. In that regard, what IPC-mechanism would be
the
best/fastest to use on Windows CE (for C/C++)?
A point to point message queue (see CreateMsgQueue) or a memory-mapped-file
would give you good perf, assuming you need all of these processes.
Yup, the database is on the flash drive. Both your suggestions would be
interesting to try. I don't know how much time it would take to move the
database into RAM though, but I'll look into it.
Far more than just "interesting". If you're writing to Flash, you can't
compare that to RAM or even a rotating-media hard drive. Flash is orders of
magnitude slower and there's no way to change that without bending some laws
of physics.
OK, so to summarize, what I'm wondering right now is:
* Does anyone have any suggestions for how I would go about monitoring the
processes more accurately than with the Process Monitor bundled with the
Platform Builder?
Remote Profiler and/or Kernel Tracker
* What IPC-mechanism would be the best/fastest to use on Windows CE (for
C/C++)?
P2P queue or MMF.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
.
- References:
- Performance issues on a CE-app that was ported from Win32
- From: Veg Anwa
- RE: Performance issues on a CE-app that was ported from Win32
- From: Veg Anwa
- Performance issues on a CE-app that was ported from Win32
- Prev by Date: RE: Performance issues on a CE-app that was ported from Win32
- Next by Date: WM 6.1 LoadLibrary() of dll with a Writeable code section.
- Previous by thread: RE: Performance issues on a CE-app that was ported from Win32
- Next by thread: FtpGetFile fails with ERROR_FILE_NOT_FOUND
- Index(es):
Relevant Pages
|
Loading