unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Magit is painfully slow
@ 2018-12-29  7:08 Brett Gilio
  2018-12-29  8:17 ` Ricardo Wurmus
  0 siblings, 1 reply; 5+ messages in thread
From: Brett Gilio @ 2018-12-29  7:08 UTC (permalink / raw)
  To: guix-devel

Hi all,

I am having the weirdest issue with the Guix repository cloned from
Savannah. Before compiling, Magit is very efficient and opens in no time
at all. However, after compiling and generating several .po and .texi
files Magit takes almost a whole minute to open. I can clean the
repository and it wont make any difference, nor does adding those .po
and .texi files to gitignore (which magit seems to not realize because
it still shows them as unstaged changes). Does anybody else have
experience with this issue, it is literally only with our Guix
repository.

Best,
Brett Gilio

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

* Re: Magit is painfully slow
  2018-12-29  7:08 Magit is painfully slow Brett Gilio
@ 2018-12-29  8:17 ` Ricardo Wurmus
  2018-12-29 16:44   ` Kyle Meyer
  0 siblings, 1 reply; 5+ messages in thread
From: Ricardo Wurmus @ 2018-12-29  8:17 UTC (permalink / raw)
  To: Brett Gilio; +Cc: guix-devel


Hi Brett,

> I am having the weirdest issue with the Guix repository cloned from
> Savannah. Before compiling, Magit is very efficient and opens in no time
> at all. However, after compiling and generating several .po and .texi
> files Magit takes almost a whole minute to open.

That’s because it’s trying to colorize the diff of thousands of lines of
.po and .texi changes.  Since these are generated automatically, run
“git checkout -- po && git checkout -- doc” and magit will be fast
again.

-- 
Ricardo

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

* Re: Magit is painfully slow
  2018-12-29  8:17 ` Ricardo Wurmus
@ 2018-12-29 16:44   ` Kyle Meyer
  2018-12-29 18:32     ` Brett Gilio
  0 siblings, 1 reply; 5+ messages in thread
From: Kyle Meyer @ 2018-12-29 16:44 UTC (permalink / raw)
  To: Ricardo Wurmus, Brett Gilio; +Cc: guix-devel

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

> However, after compiling and generating several .po and .texi
>> files Magit takes almost a whole minute to open.
>
> That’s because it’s trying to colorize the diff of thousands of lines of
> .po and .texi changes.

With the default settings and no cached visibility for the repo, the
hunks should not be expanded, so Magit isn't actually coloring/painting
them yet.  In this case, the processing of these diffs will be slow
regardless of whether they are painted and the CLI "git checkout"
suggestion is good, but I think the delayed painting is worth noting
because users may not realize that their custom visibility settings are
making things slower.

-- 
Kyle

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

* Re: Magit is painfully slow
  2018-12-29 16:44   ` Kyle Meyer
@ 2018-12-29 18:32     ` Brett Gilio
  2018-12-29 20:27       ` Kyle Meyer
  0 siblings, 1 reply; 5+ messages in thread
From: Brett Gilio @ 2018-12-29 18:32 UTC (permalink / raw)
  To: Kyle Meyer; +Cc: guix-devel


Kyle Meyer writes:

> Hello,
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> [...]
>
>> However, after compiling and generating several .po and .texi
>>> files Magit takes almost a whole minute to open.
>>
>> That’s because it’s trying to colorize the diff of thousands of lines of
>> .po and .texi changes.
>
> With the default settings and no cached visibility for the repo, the
> hunks should not be expanded, so Magit isn't actually coloring/painting
> them yet.  In this case, the processing of these diffs will be slow
> regardless of whether they are painted and the CLI "git checkout"
> suggestion is good, but I think the delayed painting is worth noting
> because users may not realize that their custom visibility settings are
> making things slower.

Ricardo,
Thank you for your suggestion.


Kyle,
What do you suggest here?

Brett

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

* Re: Magit is painfully slow
  2018-12-29 18:32     ` Brett Gilio
@ 2018-12-29 20:27       ` Kyle Meyer
  0 siblings, 0 replies; 5+ messages in thread
From: Kyle Meyer @ 2018-12-29 20:27 UTC (permalink / raw)
  To: Brett Gilio; +Cc: guix-devel

Brett Gilio <brettg@posteo.net> writes:

> Kyle Meyer writes:
>
>> Ricardo Wurmus <rekado@elephly.net> writes:

[...]

>>> That’s because it’s trying to colorize the diff of thousands of lines of
>>> .po and .texi changes.
>>
>> With the default settings and no cached visibility for the repo, the
>> hunks should not be expanded, so Magit isn't actually coloring/painting
>> them yet.  In this case, the processing of these diffs will be slow
>> regardless of whether they are painted and the CLI "git checkout"
>> suggestion is good, but I think the delayed painting is worth noting
>> because users may not realize that their custom visibility settings are
>> making things slower.

[...]

> Kyle,
> What do you suggest here?

Sorry for not being clear.  I agree with Ricardo's suggestion and wasn't
offering another one.  I was pointing out that, with the default
configuration, the lag is due to diff processing *other than colorizing*
because Magit delays painting hidden diffs.  Based on how the user
configures section visibility (e.g., via
magit-section-initial-visibility-alist and
magit-section-cache-visibility), the diffs may not be hidden, leading to
additional time spent painting the diffs.

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

end of thread, other threads:[~2018-12-29 20:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-29  7:08 Magit is painfully slow Brett Gilio
2018-12-29  8:17 ` Ricardo Wurmus
2018-12-29 16:44   ` Kyle Meyer
2018-12-29 18:32     ` Brett Gilio
2018-12-29 20:27       ` Kyle Meyer

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).