Profiling Emacs on M$

Profiling Emacs on M$

[dhruva]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Hello,
 Now that I have a working MSVC build on M$, I started with profiling
the code using Kernrate (a sampling based non-intrusive profiler by
M$). I am attaching the results for a very basic start, opening a
couple of emacs source files (font.c, files.el) and closing the emacs
session.
 The reason I am sending this is not aimed at the results but to
convey that I have an environment where I can perform easy profiling.
Do let me know if there are specific scenarios that need to be
profiled to find hot spots.

For anyone interested:
1. Download Krview from M$ site and install it (on XP/2K)
2. Make sure you run the appropriate kernrate for the arch and os type
(no 64bit support yet)

$ Kernrate_i386_XP.exe -a -j
C:\users\dhruva\stub\repo\git\emacs\src\obj-spd\i386 -z emacs.exe -wx
10  -yr emacs.kv -o emacs.exe

The generated file emacs.kv can be opened in an excel file (part of
krview) which has a bunch of VB macros that creates an excel report.

-dky

-- 
Contents reflect my personal views only!

[-- Attachment #2: emacs_kernrate.png --]
[-- Type: image/png, Size: 23328 bytes --]

Re: Profiling Emacs on M$

[Jason Rumney]

dhruva wrote:
> Hello,
>  Now that I have a working MSVC build on M$, I started with profiling
> the code using Kernrate (a sampling based non-intrusive profiler by
> M$). I am attaching the results for a very basic start, opening a
> couple of emacs source files (font.c, files.el) and closing the emacs
> session.
>   

The results show most of the CPU time being taken by garbage collection, 
which is to be expected with light use.
Since the current problems seem to be in displaying fonts, you need to 
start emacs, then make it do lots of redisplay before quitting, so that 
redisplay functions dominate.  When I do this using Free profiling 
software (gprof), it shows w32font_text_extents as being the most 
significant consumer of CPU time outside of garbage collection and 
waiting for input. It would be interesting if you can replicate those 
results, as that would prove that using proprietary software does not 
give any advantage here.

Re: Profiling Emacs on M$

[dhruva]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

Hello,

On 5/21/08, Jason Rumney <jasonr@gnu.org> wrote:
> redisplay functions dominate.  When I do this using Free profiling software
> (gprof), it shows w32font_text_extents as being the most significant
> consumer of CPU time outside of garbage collection and waiting for input. It
> would be interesting if you can replicate those results, as that would prove
> that using proprietary software does not give any advantage here.
>

Both tools give the same information, hence the point is proved.
Anyway, I was not trying to argue on that aspect, just that I am used
to kernrate (when you build using MSVC).
I normally used to build using MinGW/GCC but felt the need to work on
getting back the MSVC build too. I still find debugging with GDB on M$
not as good as debugging on GNU/Linux. Easier to use proprietary
debuggers on M$ as they can handle crash files which GDB cannot in its
current state. So, the lack of proper debugging support in GDB for M$
makes my use MSVC.

-dky

-- 
Contents reflect my personal views only!

[-- Attachment #2: emacs_kernrate.png --]
[-- Type: image/png, Size: 22878 bytes --]

Re: Profiling Emacs on M$

[Eli Zaretskii]

> Date: Wed, 21 May 2008 14:44:16 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> Easier to use proprietary debuggers on M$ as they can handle crash
> files which GDB cannot in its current state.

GDB indeed cannot be set up as a JIT debugger, but there's the DrMinGW
program that can.

Re: Profiling Emacs on M$

[dhruva]

Hi,

On 5/21/08, Eli Zaretskii <eliz@gnu.org> wrote:
> GDB indeed cannot be set up as a JIT debugger, but there's the DrMinGW
>  program that can.

I agree about the JIT part. The DrMinGW creates a file which I am not
sure if GDB can read as a core file. I tried using the cygwin dumper
to create dumps of running processes build with GCC and use it through
GDB with no success (I have been trying to migrate the complete build
in the place I work to use MinGW so that we can have same/similar
build/development/debugging environment on M$ and UNIXes).

-dhruva

-- 
Contents reflect my personal views only!

Re: Profiling Emacs on M$

[Eli Zaretskii]

> Date: Thu, 22 May 2008 09:25:14 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: jasonr@gnu.org, emacs-devel@gnu.org
> 
> On 5/21/08, Eli Zaretskii <eliz@gnu.org> wrote:
> > GDB indeed cannot be set up as a JIT debugger, but there's the DrMinGW
> >  program that can.
> 
> I agree about the JIT part. The DrMinGW creates a file which I am not
> sure if GDB can read as a core file.

DrMinGW does not generate a core file, it generates a text report
(which you can save to a file) that includes a full annotated
traceback of the crash.

> I tried using the cygwin dumper to create dumps of running processes
> build with GCC and use it through GDB with no success

I don't think the Cygwin dumper will work with anything but Cygwin
programs.