FALSE ALARM, CULPRIT FOUND: I had a MalwareBytes browser extension that slowed the emote picker down. The extension has been purged and now both the popup and the inline picker are working well.
The original post before I did testing
I try to 
in a Hexbear comment. The picture takes forever to even load in the picker so it takes a while to see if I’ve even selected the right emote. Most of the emotes in the list I can’t even see the pictures unless I step away for a minute and come back after they’ve all loaded. I hit submit comment. It takes forever to post. I can hear the fans whirring. If I’m streaming vid on blorptube while posting something from the emote picker, sometimes the video will just pause and stop loading until whatever process the emotes have kicked off completes. I don’t know why some emotes are visible while others aren’t it doesn’t appear to be related to order that they show up in the list
I think “Well I’m on the ESR of Firefox, maybe it’s just old” but then I boot into Linux with cutting-edge up to date Firefox and it still behaves largely the same.
I have wondered if it’s an internet speed thing but it seems to behave this way whether I’m on ethernet or 802.11n wireless, whether or not my VPN is on.
It also takes quite some time for emotes to load in the emote picker on Blorp, come to think of it.
I’ve got 16GB of RAM, that should be plenty. Yes I know the web has gotten more intensive since this computer was made 13 years ago but come on, compared to hell sites like twitter, facebook, and new.reddit, lemmy seems downright lightweight. NoScript and other blockers aren’t blocking a ton of bloat here.
I’m not criticizing the unsung heroic devs of Hexbear. I’m no good at web dev, hated it when I had to do it for work, and couldn’t fix or optimize this either. But I would like to understand what the root cause of this problem is and
(If the answer is “upgrade your hardware or live with it” then I’m living with it, because my precious little computer is my buddy and I’m not abandoning it)
@makotech222@hexbear.net @Edie@hexbear.net @WhyEssEff@hexbear.net @LeninWeave@hexbear.net @RedWizard@hexbear.net @BoarAvoir@hexbear.net
I’m calling a false alarm on this, and if anyone else complains tell them to disable their browser extensions 1 by 1 to test if any are slowing it down. I had an extension from MalwareBytes that was slowing it down. I’ve since removed that and the popup emote picker is fast again. I should have thought to test all that before asking for technical help. My apologies.
Oh interesting. What was the extension exactly?
MalwareBytes Browser Guard, which I have long thought was probably superfluous anyway since I’ve got unlock Origin, but I didn’t see a harm in having it
Because there are so many emotes that don’t actually get used, that end up there because someone once thought “hmm I think I’ll put that as an emote”. This is not merely a problem with loading thumbnails, but with the idea of using them as a means of communication in general.
I’d love to see a list of how much each emote has been used, and especially which ones have been used less than 10 times.
Lol @ the suspicion that “you must have more than 16 GB of RAM to use this webb sight” tho
Didnt read allat, the emote library is the crown jewel of this site, this shit turned slow overnight.
One of you nerds did something, I know it, I need it fixed stat
it’s been laggy as shit for years, if it suddenly got worse recently i can’t say i noticed
edit: i have noticed comments taking longer to go through after hitting send though, that’s been happening for just a couple months i think. different issue but possibly related by the timeframe
if they contain an emote they are slow, might be some image fetching mechanism
I thought it was laggy on my phone and it is but actually what it was doing was loading the emoji picker way down the screen if i started typing characters too fast after the :
I’d been dealing with it by starting over and typing slowly which would have it appear in my view but now it’s just like oh i guess i just have to scroll down
I’d love to see a list of how much each emote has been used, and especially which ones have been used less than 10 times.
Love that idea.
16 GB
Well comrade 9to5 has 32GB RAM and doesn’t have this problem. Coincidence?
I didn’t verify this with technology, but feels to me like you use almost your entire rate limit on the first page before it’s possible to search anything, them if you don’t find anything on your first search, nothing else bothers to load if it’s not already loaded or cached. Hard to say it’s for sure rate limit, but doesn’t feel like a problem of slow device to me. Maybe the emoji menu should implement pagination? And/Or exclude emojis from rate limit?
I disagree, the emoji are amazing, especially the obscure ones. I think this can probably be solved with a technical solution, like @makotech222@hexbear.net implemented.
if I could load all the emotes, maybe I’d try more of them lol
5·2 days agoI’d love to see a list of how much each emote has been used, and especially which ones have been used less than 10 times.
Someone give me a dump of the comments from the database.
I’ve pushed an update to lazy load all the images instead of trying to load them all immediately. Should help a bit with both the emoji pickers.
What is lazy loading? Test post:
Alright I think that helps the in-line colon keyword colon method. Smiley face emote picker still behaves as before but this is a step up, thank you!
Lazy loading means that the browser only starts loading once the image is needed. So before it was “eager”, meaning it would load the images immediately, whereas now it will wait until they are actually shown.
html image element has ‘loading’ attr; when set to ‘lazy’ it will only make the http request when the img is in the viewport. default option is ‘eager’ which loads it when the page is loaded.
Wow, what a difference in speed! I thought it was already lazy loading, I didn’t realize it was loading them all at once.
the problem (on the images side, less familiar with the codebase) is partly an optimization problem with some images that still need to be downsized after the refork. Day-ish of grunt work I haven’t found a slot for?
But yeah, I agree that there’s also an issue with quantity in a sense, less raw quantity but more so the accumulation of amount of data you need to load. I’ve been much more hesitant to do large batches of additions recently and instead have been largely adding emotes on a one by one basis when I do so.
I have to find a time to assess what I can do on my end, unfortunately I have like 50 things going on ATM so
If you can instruct me on what to do, I’ve got a gamer rig, funemployment time, some crude graphic design experience, and the power of autism available.
It’s the least I can do to pay you back for that God of the Dead mega-mix I keep on my pump up playlist.
I would put a salute emoji here, but, well…
@WhyEssEff@hexbear.net @Thordros@hexbear.net
I have some technical knowledge of python, unemployment, and autism, and I’d be interested in helping automate a downsampling procedure if we can come up with good logic for it. The fear I have is just running a 50% down sample on everything without sensible thresholding could break some images.
I was thinking of this recently, and the other thing I noticed is that the emotes reload extremely often for me, even when I use them multiple times a day. Are they not configured to be cached? This might be an issue on my end.
This is a crime against all hexbears and we must liberate every emoji from loading jail.
No one is free until the Hexbear emojis are free.
I think the emotes need a better cache policy and possibly some pre fetching and more optimized lazy loading and cheaper thumbnails. I’ve done a lot of this type of work for like e-commerce sites, its annoying and tedious, but it is possible to make this type of thing fast on most devices.
I have intentions to help with hexbear tech, but I haven’t got around to it yet.
Speaking of, is guthub the only way to contribute? Cuz I’m probably not gonna make an account on there.
We could and have also accepted patches other ways (matrix primarily) but it’s currently the primary place. I’d appreciate any contributions! If you are on matrix reach out to carcosa or me about getting added to a dev chat when/if you’re ready
Most of the time, if I’m trying to post a comment:
-
I need to type everything in the comment box and click the submit button.
-
Select All and Cut everything out of the comment box while the hexbear logo is spinning in the submit box.
-
Click the Reload Page button. A little box with “Type Error” pops up at the bottom of the screen.
-
After the page reloads, paste everything back into the comment box and click submit. 90% of the time it works like a charm.-
This is concerning. It’s certainly not ever been bulletproof but it shouldn’t be failing out anywhere near every time (the Type Error is I think, expected when reloading while a request is in progress, but I’m assuming you reload because otherwise it never successfully posts?) Any further errors you can share? the developer console/network tab can show a lot of useful details but I’m not even sure where to start with this one. OS and browser details, I guess?
edit: and this comment posted pretty much instantly for me, using a firefox fork on a like 4 year old linux box
the Type Error is I think, expected when reloading while a request is in progress,
Good to know.Typically I’m lacking in patience to wait. Sometimes I’ll have multiple tabs open and just click the submit button and go do other things. On rare occasions, after clicking submit while the spinning hexbear icon is doing its thing and seems to be stalled, I can reload the page and the comment will have posted.
Linux Mint, basic Firefox with Ublock and NoScript, on a frankenPC with a few parts that have got to be close to 20 years old by now (which is why I don’t think to mention it when skimming posts/comments about the site misbehaving).
I posted in c/hexbear about this recently, several other users are experiencing this:
Thanks, I had missed that. Looks like a significant issue then
100% of the time if I open another Hexbear tab and wait for that to load (a long time sometimes), once it has my comment in the first tab will have also posted.
-
true good posting takes time and patience
Oh sure, the pig shitting on its balls loads instanly though
From extensive reverse engineering and ux testing I have concluded that PPB is probably hard-coded as the first element in the emote list. It’s the equivalent of letting us all carry with a round already in the chamber.
source:
I did none of that and made it up
It seems like two-wolves-1 is the first in the list.
Yes to be clear my comment was a jokd., in response to what I assumed was also a joke.
Yes I saw your spoiler, I was just curious what the actual answer was
@Thordros@hexbear.net, @CommunistCuddlefish@hexbear.net You can find the repo that contains all the emoji here: https://github.com/Hexbear-Code-Op/hexbear-emotes and I think there is a full size and a reduced size folder contained within. You might want to look at imagemagick for bulk image conversion and resizing.
Though, it might be more that @WhyEssEff@hexbear.net needs to literally log in and manually re upload smaller versions of the emoji through this interface:
(this is from my instance)And that interface is not great. Looking at it right now, I don’t even think there is an option to “reupload” an emoji; you might have to delete it and re-add it, which I think is what the actual time crunch would be.
Now, all that said, if you wanted to go fucking ham on this issue, you could use the CustomEmoji endpoint: https://lemmy.readme.io/reference/put_custom-emoji to automate the process of Fetching, then Deleting, then recreating the entire emoji list. You would need to have the Emoji hosted somewhere on the internet for it to work, but, that could be the GitHub repo. I assume when you provide it the image URL it automatically pulls the image from the remote location to the Lemmy server.
So, in theory, there is a tool waiting to be built that would allow you to not only point your instance at an emoji GitHub repo and import it, but periodically sync the emoji from GitHub itself. Obviously, that’s outside the scope of the issue here. What is needed is just a script that can replace the existing emoji with smaller versions, retaining their short code and other data.
Edit:
If you wanted to get a JSON object of our big, beautiful emoji list, it’s here: https://hexbear.net/api/v3/site look under “custom_emoji”. (2749 objects! Woof!)
I will likely have a chance to look at this in more detail on Sunday, thank you for getting us started!
Question: Do we have a good way to test what is even causing the bottleneck? Do we know it’s emoji size, or is it the sheer # of emojis? Asking because, for example, it takes longer to cp 1GB of very small files than it does to cp a single 1GB file, because the file open/close operations take up the bulk of the processing power.
Loading is slowed down by each emoji being it’s own HTTP call.
In that case it sounds like # of emojis rather than size of emojis is at least one bottleneck.
Wonder if there’s a way to do a profiler test of the performance. There must be but I am pulling quarter-understood concepts out from beyond the veil of memory
Yeah there are like 2700+ emoji. The emoji is sectioned, if you could gate what is loaded by its section it could speed things up. Load the emoji in batches by section basically. It is like 2 gig of emoji at full resolution. There are a lot of gifs that could be converted to apng (animated PNG) to reduce the size.
I wonder if HTTP/2 would help.
We already use it
Oh, I misread, firefox reports HTTP/1.1 for cached responses even if the original req was HTTP/2 it appears
i just have the entire emoji list memorized so i can always summon the perfect one at will and not even need to preview it.
Yeah I’ve been trying to do that but sometimes I want to browse for new emotes
It would be really helpful if there was a page that listed all if the emotes so that I can tab over to it and have all of the options loaded for me to pick out.
I also like that browser extension idea 🤔
Happy anniversary of joining Hexbear, Mr. Future President. If I might make one small request, as a constituent, would please consider making your next campaign slogan be “AmeriKKKa delenda est”?
there used to be in c/emoji but the person who went through that effort deleted their account and those comments unfortunately
Hexbear itself is slow for me unless I’m using an Lemmy app on my phone.
The entire internet is kind of slow for me on a computer unless I’m using an app on my phone.
When you refer to the emote picker, do you mean the one that pops up when you start typing out the shortcode (e.g. :fidel ) or the one above the text input box under the little smiley icon?
Both have performance issues to some degree, but there probably isn’t much you can do on your machine about it. Maybe there’s some sort of extension that can force cache them? It’s something we’ve tried addressing from the server side in the past with limited success, but it could use more work.
I mean both. Here’s a pic of what I see 2 seconds after clicking the smiley icon:
Here’s a pic of what I see 2 seconds after typing “:fidel-” in this comment input field:
If there’s nothing I can do about it because it’s server side then there’s nothing I can do about it. Ultimately it’s a minor annoyance. I tried glancing through the Hexbear code on Github to see if I could try to diagnose the problem and all I got from it was a reminder that I am terrible at web dev.
So im not kidding when I say the emotes pop up almost instant for me but I also got a 32gb of ram and a pretty beefy rig.
EDIT : Im gonna say something controversial I LOVE our emojis/emoticons but I also think we probably have about 50% to many and should consider cutting down “some” of them to make it user friendlier
I have access to a powerful computer with 3x as much RAM, and it still loads hella slow on there.
I guess my pc is just built differently then
( seriously though im aware lots of folks have different problems with the site this is just one of them)
