all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-09 17:08 Eighty Megabytes
  2019-07-09 17:27 ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-09 17:08 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

> I have no idea how rpgrep works, but if it accesses some database,
> perhaps it takes time when the database is not in the system's disk
> cache?

Then it would be slow from the command prompt too. I tried it first
from the command prompt and it was instantaneous. Then I switched to
emacs and run the exact same command again via call-process and it
took 6-7 seconds. (If I then try immediately from the command prompt 
again then there it's instantaneous again,)

> This is pure guessing on my part; please let's use a command
> that is likely to be on any Windows machine.

I tried it with grep and I don't see the slowdown there, so I'm
out of ideas. (Simply using grep is not the answer, because
command line ripgrep is several times faster than grep, that's
why I wanted to use it from emacs too.)

I'll think of other ways of tracking down the problem. E.g. using
some systrace tool or something too see where emacs spends that
6-7 seconds.
 


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-10 21:10 Eighty Megabytes
  0 siblings, 0 replies; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-10 21:10 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

> IME, anti-virus software is generally OK (with minor exceptions --
> there are a couple of them that should be avoided at all costs), but
> you need to configure it so it gets out of your way.  For example,
> binaries that you build yourself should be exempt from having all the
> files they open examined, it's enough to have the binary itself
> examined (to make sure no malware attaches itself to it).  I suspect
> Emacs in your use case is one such program.


Only the default Windows Defender is on my machine, but it cannot
be configured, so a binary is "exempt from having all the files
they open examined". I can exclude processes from the check, or
directories, so in this case excluding source directories seemed
to be the way to go.

This made Dumb Jump usable for me on Windows. Dumb Jump is a code
navigation package which does not require building tags tables at
all (so they can't go out of sync), because ripgrep is so quick
that it simply greps the code to find the relevant location when
you want jump to it and it's instantaneous, especially after the
first run when the OS caches the source files in memory.
 


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-10  8:34 Eighty Megabytes
  0 siblings, 0 replies; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-10  8:34 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

> Even the respectable newspaper websites these days contract with ads agencies to
> 
> fill the borders of their web pages with random ads.
> And random ads are just that. We may never know what will be shown there.
> 
> There *HAVE* been reports of such random ads that insert malware into our PCs.


If the browser is the vector then  the solution could simply be running the browser in a sandbox
isolated from the rest of the system, so you don't need to do an antivirus for everything else.

Sure, a very determined attacker could break out of the browser and the sandbox around it,
but in practice most attackers care about infecting average users, so they don't think
about being in an other sandbox after cracking the browser's defenses.


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-10  5:31 Eighty Megabytes
  2019-07-10  6:08 ` ISHIKAWA,chiaki
  2019-07-10 14:33 ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-10  5:31 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org


> One more case of virus software being not just useless but even harmful.
> Just say no!

I wonder what the practical infection vectors for windows these days
if one is careful about installing stuff.

I don't install random binaries from the net. I do install precompiled
exes, but those are from known sources (e.g. git, emacs, etc.). 

Firefox is a possible vector, because one visits lots of random sites with
it, so it may be possible that a site exploits some yet unknown security
hole.

So the question is: does the latter warrant running a virus a scanner or
is the danger so low that it's better to keep windows defender off?



^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-09 20:54 Eighty Megabytes
  2019-07-09 21:30 ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-09 20:54 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

> What kind of program is ripgrep?  Is it per chance a Cywgin or MSYS2
> executable?  If so, perhaps the time you see is spent loading the
> Cygwin/MSYS2 DLL.

I ran the emacs test about 5 seconds after the command prompt test.
so I don't think windows would forget about the already loaded
DLLs in a such a short time.

I tried to trace the process and it seems to me when the search is run
via emacs then windows defender checks every source file read by ripgrep
and I assume this slows down the search.

When tracing an invocation via the command prompt then there are no checking
of source files, so it looks like windows defender thinks emacs is a suspicious
program or maybe it considers the invocation of cmdproxy.exe  suspicious.

With windows defender turned off for the given source directory the delay
practically disappears.


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Does emacs cache something on windows when invoking call-process?
@ 2019-07-09 15:58 Eighty Megabytes
  2019-07-09 16:16 ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-09 15:58 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org



> From:     Eli Zaretskii
> 
> This doesn't happen to me: I get instantaneous response from Emacs as
> well.  On the first attempt as well on the subsequent ones.

It does for me too usually with other commands.

It's ripgrep.

If I invoke simply ripgrep --help via emacs call-process then it's instantaneous:

"c:\\bin\rg.exe" --help

But if I do this search with it via call-process, so (call-process "c:\\bin\\rg.exe" nil t nil  args...))

"c:\\bin\rg.exe" --color never --no-heading --line-number -U --pcre2 --type php "function\s*fetch_object_info\s*\(|\*\s@method\s+[^ ]+\s+fetch_object_info\(|(\s|->|\$|::)fetch_object_info\s*=\s*|\*\s@property(-read|-write)?\s+([^ ]+\s+)&?\$fetch_object_info(\s+|$)|trait\s*fetch_object_info\s*\{|interface\s*fetch_object_info\s*\{|class\s*fetch_object_info\s*(extends|implements|\{)" c:/proj/test

then it takes 6-7 seconds from Emacs.

This search returns a single line as a result. It is run on a codebase of several dozen files, so not a huge codebase.   The exact same command always returns the resulting line instantaneously from a command prompt.

And that's what I dont't get that how it is possible that the exact same command is immediately gives the result from the command prompt and takes 6-7 seconds from call-process.

> 
> Do you have some antivirus installed, per chance?

Just the default windows defender. 

> 
> > 2. What does that first call-process call does/caches in emacs which makes 
> > subsequent calls quick until it forgets something and it's slow again?
> 
> AFAIK it does nothing inside Emacs or by Emacs.  It might do something
> on your system level, though.  But that's out of scope of Emacs.

If it happens on the system level then shouldn't it affect the same command when executed via a command prompt?

 


^ permalink raw reply	[flat|nested] 13+ messages in thread
* Does emacs cache something on windows when invoking call-process?
@ 2019-07-09 14:03 Eighty Megabytes
  2019-07-09 15:27 ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Eighty Megabytes @ 2019-07-09 14:03 UTC (permalink / raw)
  To: help-gnu-emacs@gnu.org

I have the same search command line which is practically instantaneous in the windows command prompt, but it takes several seconds when executed via call-process.

So I try it in the command prompt, it's instantaneous.

Then I try the same command line from emacs via call-process and it takes several seconds.

Subsequent calls via call-process are instantaneous until I don't use the feature for a while. Then the next invocation from emacs becomes slow again.

So this behavior raises 2 questions:

1. Why is the same command much slower when invoked via call-process?

2. What does that first call-process call does/caches in emacs which makes subsequent calls quick until it forgets something and it's slow again?

 


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2019-07-10 21:10 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-09 17:08 Does emacs cache something on windows when invoking call-process? Eighty Megabytes
2019-07-09 17:27 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2019-07-10 21:10 Eighty Megabytes
2019-07-10  8:34 Eighty Megabytes
2019-07-10  5:31 Eighty Megabytes
2019-07-10  6:08 ` ISHIKAWA,chiaki
2019-07-10 14:33 ` Eli Zaretskii
2019-07-09 20:54 Eighty Megabytes
2019-07-09 21:30 ` Stefan Monnier
2019-07-09 15:58 Eighty Megabytes
2019-07-09 16:16 ` Eli Zaretskii
2019-07-09 14:03 Eighty Megabytes
2019-07-09 15:27 ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.