[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: org batch job using emacsclient?

From: Sebastian Rose
Subject: Re: [Orgmode] Re: org batch job using emacsclient?
Date: Tue, 17 Nov 2009 13:16:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Stefan Vollmar <address@hidden> writes:

> Dear Sebastian,
> many thanks for your detailed reply!
> On 17.11.2009, at 03:25, Sebastian Rose wrote:
>>> To start with, it now works for me and I can measure a consistent speedup of
> 7x
>>> (!) for using emacsclient - in an interactive web service (conversion of
>>> org-files to HTML) the difference between 0.35 s and 2.40 s (average) is
>>> significant.
>> That was to be expected :)
> I had certainly hoped so. However, this performance is still disappointing
> considering the "horse power" of modern systems - and this although I checked
> that all Lisp sources have been compiled. But I will now officially stop
> whining: < 0.5 s for a typical interactive query is acceptable from a user's
> point of view.
>>> I have added a (kill-buffer) statement for cleaning up (I observed an
> increasing
>>> number of emacsclient processes before), is this a good solution?
>>  Does it help? Then I think it's ok.
>>  The `usual' way to close a server buffer is `C-x #' which is bound to
>>  the function `server-edit'.  That's what I use in org-protocol.el. The
>>  name is somewhat confusing, though.
> +1
>>     /path/to/emacs -Q -l /etc/emacs-server/init.el --daemon=SERVER-NAME
>>     /path/to/emacsclient --no-wait --socket-name=SERVER-NAME xy.org
> (1) I have changed the code to 
> #!/bin/sh
> emacsclient --no-wait -s org
> --eval "(progn
> (add-to-list 'load-path \"/opt/org-6.33c/lisp/\")
> (require 'org)(require 'org-exp)
> (setq org-export-headline-levels 2)
> (find-file \"$1\")
> (org-export-as-html 2 nil nil nil nil \".\"))"
> omitting the (kill-buffer) is a speed improvement and no emacsclient processes
> remain - nice! However, what happens to any buffers, temporary or otherwise,
> created during org conversion - will they accumulate in the server process?

Hm - I'd guess so. You could find out by simply opening lots of files
the way you use emacsclient.


  for f in $(find /etc/ -type f -name '*conf'); do
     emacsclient --no-wait "${f}";

makes my emacs process grow quite a bit, as `ps aux | grep emacs' shows

Maybe even add a function to your emacs-server to log the opening and
closing of files together with a timestamp? E.g. advising `find-file'
and `kill-buffer'.

> (2) I have not tried but it is probably important to start emacs-server as the
> same user who is then going to run emacsclient (root vs webservd)?

I did - it is necessary, since the socket is read- and writeonly for the

  <address@hidden:/home/sebastian> ls -l /tmp/emacs1000/
  insgesamt 0
  srwx------ 1 sebastian sebastian 0 2009-11-17 12:17 server
  <address@hidden:/home/sebastian> su - emacs22
  address@hidden:~$ /usr/local/bin/emacsclient --no-wait -s \
                        /tmp/emacs1000/server xy.org
  /usr/local/bin/emacsclient: can't stat /tmp/emacs1000/server: Permission 
  /usr/local/bin/emacsclient: error accessing socket "/tmp/emacs1000/server"


> (3) 
>>  Are you familiar with init.d stuff? There is an example file somewhere
>>  on Debian...
>>  http://github.com/SebastianRose/denycc/blob/master/scripts/rc.denycc
>>  is made from such an example file for Debian 4.0
> Yes, I still grew up with this. However, this is (slightly) deprecated on
> Solaris 10: we are supposed to use services instead,
> http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.jsp (I have been
> happily using this feature of Solaris 10 but so far not created a new service
> which would be required here).

Is this in OpenSolaris that way too? I should install it in my VM.

On Linux we now have this /etc/event.d/ - I think I read something about
it... the /etc/init.d/rcX mechanism has changed somehow. Not sure
though. I have put this on my list.

Best wishes


reply via email to

[Prev in Thread] Current Thread [Next in Thread]