Re: Tooltips GC overhead

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Fri, 07 Aug 2015 10:52:34 -0400
> 
> > Just looking at the implementation of Fcons, I find it hard to believe
> > a single comparison can have any significant effect on its efficiency.
> > So I'm unsure how this could be of any practical concern.
> 
> Fcons is a core operation executed fairly frequently, so any slowdown
> (no matter how small) needs to be justified by a major advantage.

Without some kind of quantitative criterion, this sounds irrational to
me.  Would a 0.001% slow-down be acceptable?  How about 0.1%?  There
must exist some threshold below which any slow-down can be ignored,
and the question I'm asking is what is that threshold?

> >> > In any case, it's much better than the current useless profile.
> >> I'm not convinced it'd make it sufficiently better
> > Well, it allowed me in this case to identify the source of the problem
> > quickly, efficiently, and accurately.
> 
> IIUC, something *else* allowed you to do that.

That something else was a watchpoint put on the variable, followed by
semi-manual computation of the frequency distribution of functions
that caused the watchpoint to fire.  That's exactly what a profiler
would have done for me, if it were looking at that variable instead of
counting calls to malloc.

> Until I have positive proof that the extra precision is useful in some
> cases, I'll reject such changes in the default build.  So it's either
> "rejected" or "depends on a compile-time option" for now.

Too bad.