[BUG] Terrible performance on own profile page (Firefox only) about github-defreshed HOT 17 CLOSED

Don't remember about Ubuntu, but most Linux distributions doesn't support emojis out of the box, so, yeah

this is awful

Microsoft ¯\(ツ)/¯
(To be fair, I'm 80% sure this problem existed before them, but I just can't miss this opportunity to blame them :))

from github-defreshed.

Does this happen only on your personal page when you're logged in? I have some ideas, but want to ensure

Yes, only on my own profile page. I may try logging in to an another account I have which has less contribution activity (but yours have more but doesn't lag, so it's probably not an issue)
UPD: yes, this happens on my second account too, even though it had no activity in a year. So this issue is related to viewing your own profile only, not others

As I can see, styles recalculating took like few ms in total, so it's definitely not a problem

Hmm, at least thats what I saw in firefox window before exporting the profiler dump

Also I can't help but say that I really appreciate that you took time to record a video and make a profiler dump!

It's the least I can do (:

from github-defreshed.

Don't think it's an evil move, just sort of very "dum-dum" move

At first, I thought that these guys were unaware that some systems have no built-in emoji support, so fallback-src was designed primarily for custom GitHub emojis like Octocat (:octocat:), and there're very few of them. It's still bad that we load all of these as separate images, but 4 or 5 files aren't nearly as bad as thousands

But then I went curious about their emoji-support detection system and how it works, since I know no reliable methods to implement such a thing. So I dug into GEmojiElement.toSting() and found that thing I've sent before

So they were aware but somebody decided that downloading thousands separate images is good idea ¯\(ツ)/¯

from github-defreshed.

@MrNaif2018, hm, it's interesting. I'm Firefox user too, and I can't replicate it on my Windows and MacOS machines.

Your own profile page

Does this happen only on your personal page when you're logged in? I have some ideas, but want to ensure

I don't really know how to read it, but from what I see, recalculating styles takes most of the time

As I can see, styles recalculating took like few ms in total, so it's definitely not a problem

Also I can't help but say that I really appreciate that you took time to record a video and make a profiler dump!

from github-defreshed.

The most important thing that has profile page when you're logged in (which differentiate it from other profile pages) is the status editor. Could you, please, enable Disable the status editor on the profile page option and try to reload your profile page again?

from github-defreshed.

Hooray! Haha, thank you very much!
It fixed the issue!
Although I don't use any password managers (I don't think that gpg keyring counts), it helped.
So maybe it could be a default in later versions unless it does some ugly modifications?

from github-defreshed.

@MrNaif2018, at least it works now :D

I use Dashlane, and I can reproduce similar issue when and only when it's enabled. It also happens without GitHub Defreshed. So, yeah, in my case the cause is definitely not the userscript :)

Okay, now that we figured out that the problem is the status editor, could you check, please, does the problem remains without GitHub Defreshed? (Open the status editor at your profile page to "load" it, because some modifications that the script makes just lead to the fact that the editor is loaded automatically)

from github-defreshed.

So maybe it could be a default in later versions unless it does some ugly modifications?

You're unable to change your status with this option enabled, is it "ugly modification"? :D
I was hoping to remove this option soon, as I've already sent a request to fix the problem. But here we're :)

from github-defreshed.

Okay, now that we figured out that the problem is the status editor, could you check, please, does the problem remains without GitHub Defreshed? (Open the status editor at your profile page to "load" it, because some modifications that the script makes just lead to the fact that the editor is loaded automatically)

Without the extension it works without any issues (EDIT: actually I am not sure. The page is slower than usual when opening the status editor, but I can't reproduce the exact same behaviour as before. Sometimes I get lags, sometimes not. And they are not as long as they were with the extension enabled)

And I can change my status with this modification, maybe only not the icon itself (:

from github-defreshed.

And they are not as long as they were with the extension enabled

Yeah, noticed it too with my password manager-caused problem. It looks like the emoji editor interferes with a lot more stuff when it starts loading too early

And I can change my status with this modification, maybe only not the icon itself (:

The icon is the most important part of the status! :)

from github-defreshed.

TLDR: emoji-picker is junk that causes hard times to a lot of things, so I should remove that side effect which loads it automatically

Noted, will be fixed in the next version

from github-defreshed.

Exactly! Was this emoji-picker in previous design of github or not? Anyway they did a bad job when creating it, as I can't imagine what can cause so much lags.

Thank you very much for your help! I hope that this will soon be fixed in the upstream github design (maybe, or instead they add some fancy design things instead of fixing existing ones :D )

But this fix will be it for now.
Thanks!

from github-defreshed.

Hey! Took a closer look at your profiler dump. I think, I know what's the problem and why I can't reproduce it.

emoji-picker has a "backup plan" in case font being used doesn't support emojis. And this fallback is implemented in the most shitty (I'm sorry, but it's the most soft word for such an implementation) way possible: each (!) emoji is loaded as a separate (!) image. I'm a backend-developer to the core of my mind, I don't deal with the issues that frontenders are engaged in, but even I can think of many much better and more optimal ways to do such a thing.

Apparently, your system font used in this element doesn't support emoji (maybe it does, I don't know how exactly their detection system works). So your browser is kinda busy downloading fricking thousands of images:

Sometimes I get lags, sometimes not

And it's all up to caching system, that's the answer to this mystery

from github-defreshed.

Exactly! Was this emoji-picker in previous design of github or not? Anyway they did a bad job when creating it, as I can't imagine what can cause so much lags.

Yep, it was. I don't think it was the same as its current version, but the general idea was in place

Thank you very much for your help! I hope that this will soon be fixed in the upstream github design (maybe, or instead they add some fancy design things instead of fixing existing ones :D )

You're welcome)

Also, I'll leave the issue open for now, so I won't forget to fix that thing I was talking about earlier xD

from github-defreshed.

emoji-picker has a "backup plan" in case font being used doesn't support emojis. And this fallback is implemented in the most shitty (I'm sorry, but it's the most soft word for such an implementation) way possible: each (!) emoji is loaded as a separate (!) image. I'm a backend-developer to the core of my mind, I don't deal with the issues that frontenders are engaged in, but even I can think of many much better and more optimal ways to do such a thing.

Apparently, your system font used in this element doesn't support emoji (maybe it does, I don't know how exactly their detection system works). So your browser is kinda busy downloading fricking thousands of images:

Oh my god. I am a backend developer too, and this is awful. Now I can understand why it was lagging. Thanks for this, I will check my system font (I guess Ubuntu Regular)

from github-defreshed.

Welp, part of the source code of the g-emoji element:

connectedCallback() {
    if (null === this.image && ! function () {
            const
                t = /\bWindows NT 6.1\b/.test(navigator.userAgent),
                e = /\bWindows NT 6.2\b/.test(navigator.userAgent),
                n = /\bWindows NT 6.3\b/.test(navigator.userAgent),
                r = /\bFreeBSD\b/.test(navigator.userAgent),
                i = /\bLinux\b/.test(navigator.userAgent) &&
                !/\bAndroid\b/.test(navigator.userAgent);
            return !(t || e || n || i || r)
        }()) {
        const t = this.getAttribute("fallback-src");
        if (t) {
            this.textContent = "";
            const e = function (t) {
                const
                    e = document.createElement("img");
                return e.className = "emoji",
                    e.alt = t.getAttribute("alias") || "", e.height =
                    20, e.width = 20, e
            }(this);
            e.src = t, this.appendChild(e)
        }
    }
    this.hasAttribute("tone") && sn(this)
}

As you can see, Microsoft wants Linux and FreeBSD users to suffer, heh. There's nothing to do with your system font, it's only about OS you're using

from github-defreshed.

Ah, I see. Evil anti-linux move. Thanks for showing me this, microsoft is not my go-to choice anyway in terms of job opportunities (:
Then this patch is indeed essential

from github-defreshed.