Re: fontlock-speed
Its more because most profiling has been done using quantify and that
doesn't like the dumped state of the executable. But if its works for you
then great!
I have a feeling that there are hooks in the code to turn on profiling once
XEmacs has come up, so that the startup delay does not matter.
andy
At 11:37 AM 2/12/02 -0600, Jerry James wrote:
On Fri, 08 Feb 2002 at 16:01:58 -0800, Andy Piper
<andyp(a)bea.com> wrote:
> Generally for profiling you should run temacs *not* a dumped xemacs. I
think
> make run-temacs should do this for you.
Why is that? Because of the problem I described with the static
variable? Or are you worried that a dumped xemacs will start up with
profiling data from temacs loading and dumping Lisp files? If the
latter, that does not seem to be the case. I just did two runs, one
with "make run-temacs" and an immediate shutdown:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
30.22 1.62 1.62 14326733 0.00 0.00 mark_object
10.07 2.16 0.54 173 3.12 3.12 compact_string_chars
9.33 2.66 0.50 260887 0.00 0.00 re_match_2_internal
3.73 2.86 0.20 173 1.16 1.16 sweep_conses
...
and one with the dumped xemacs and an immediate shutdown:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
24.40 0.41 0.41 253616 0.00 0.00 re_match_2_internal
7.74 0.54 0.13 1079760 0.00 0.00 mark_object
5.95 0.64 0.10 1617028 0.00 0.00 readchar
4.76 0.72 0.08 45265 0.00 0.00 read_atom_0
...
Clearly, the dumped xemacs did not include the times from the run of
temacs in its profiling output. In fact, this seems to argue that it
would be better to profile the dumped xemacs and not temacs, since the
latter will be skewed due to loading up lisp. Or is there some other
lurking danger of which I am unaware?
--
Jerry James