From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Emacs benchmark workload to run and time instead of hunch performance Date: Wed, 09 Jul 2014 19:03:34 +0200 Organization: Aioe.org NNTP Server Message-ID: <87fviaqxax.fsf@debian.uxu> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1404925535 15703 80.91.229.3 (9 Jul 2014 17:05:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jul 2014 17:05:35 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jul 09 19:05:28 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X4vJ9-00073k-1v for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Jul 2014 19:05:27 +0200 Original-Received: from localhost ([::1]:32914 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X4vJ8-0008NT-A7 for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Jul 2014 13:05:26 -0400 Original-Path: usenet.stanford.edu!news.kjsl.com!feeder.erje.net!eu.feeder.erje.net!newsfeed.datemas.de!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 70 Original-NNTP-Posting-Host: SIvZRMPqRkkTHAHL6NkRuw.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:HGW+43Mno42tlXr9I6S8lwl/YZ0= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:206336 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:98599 Archived-At: Robert Thorpe writes: > I get ~0.028 for emacs -Q and ~0.03 using my init file. >From the Emacs man page: -q, --no-init-file Do not load an init file. --no-site-file Do not load the site-wide startup file. [...] -Q, --quick Similar to "-q --no-site-file --no-splash". Also, avoid processing X resources. So yes, it seems this method is correct: emacs and 'emacs -Q' should be identical if in the emacs case, there aren't any init, startup, or X resources files. >> Keep calling it I guess it ends up in a cache >> because it gets much faster - but the emacs -Q is >> still faster. > > That's not the reason. > > Do (elp-instrument-function 'man). It'll tell you > that for the single-run case much of the time is > spent in (man "ls"). The Emacs "man" command works > by calling the system man command which typesets the > man page from it's troff source then pipes it to > Emacs. The Emacs man command first checks if the man > page is already open in a buffer, if so it just > switches to that buffer. So, on the first interation > of your benchmark you have the system man program > performing typesetting, then on each later iteration > it does nothing. To make the benchmark fair you have > to kill the man buffer before each run. OK. Didn't anyone ever attempt to write a serious workload that would take into account all things like that? It is a very basic idea so I would be very surprised if no one did it before, larger in scope and correcting such details as the one you mentioned. > Of course cache effects still make the benchmark > quicker for repeated runs. That's partly because of > the processor's cache, but also because Linux's > file-system cache will store the man page's source > file. (It goes below 0.01 for me). OK. > I don't know. Try dividing you init file into two > halves. See if the first half or the second half > causes the slowdown. When you've found which half it > is divide that into halves too, and so on until > you've found the culprit. Yes. But I'll hold my breath for a while to find out if no one did this before. I don't want to do organized testing with that workload. Also, my modules-loaded-and-configured Emacs is absolutely not slow - it is just that 'emacs -Q' seems (and is, as seen) just a tiny bit snappier. -- underground experts united