Can we use JavaScript to go faster than C++ in Ladybird?

[@egemengol306]

"Implement parts of our JS engine in JS and gain performance benefit from it" ...writing down to my notebook of sentences that have not been uttered ever

[@lunarmagpie4305]

😂

[@pixl_xip]

"And the sausage stops growing" Never heard that one

[@Whateverworksism]

Thanks for all you do Andreas and also thanks for uploading to youtube, I enjoy it. I wish you a good weekend.

[@awesomekling]

Thanks for stopping by! I wish you a good weekend as well

[@theevilcottonball]

\x1b[0;30mIs this how you do it?

[@theevilcottonball]

color now?.

[@theevilcottonball]

How did you color :^) and how did you do it that when I copy it I only get "caret"

[@pp00ww]

@@theevilcottonball You have to become a channel member to use that emoji.

[@relakin]

Yes! Finally got an hour long video. There is no other channel that I can just sit and watch someone for an hour straight and still wish that the video was longer. Thanks for posting!

[@sammmba]

Careful with the `typeof R === 'object'` because in javascript `null` is also an object!

[@REALsnstruthers]

interestingly enough, this is actually more of a misfeature than a bug. in the earliest javascript engines, there was a feature called “liveconnect” which allowed for direct interoperability with java classes. unfortunately, because all java objects are nullable & in spite of javascript already having undefined (in practice if not necessarily defined as a keyword until quite a bit later), javascript ended up with an empty, nonexistent object called null which technically has a typeof object

[@RubenKelevra]

I mean, you could also compile those to byte code while compiling lb, so you don't have to compile them to byte code on execution. :)

[@Daktyl198]

I'm sure he knows. This sounded a whole lot more like a "I wonder if this would work" type of thing.

[@somebodystealsmyname]

The bitmask optimization should go into LB regardless of the other tests you did.

[@awesomekling]

Certainly yeah, just gotta clean it up!

[@somebodystealsmyname]

@@awesomekling That optimization was not that hacky, should be easy to polish up.

[@michal_havlicek]

Well Hello Andreas!

[@awesomekling]

Well Hello Michal!

[@miko007]

i may be missing something here, but if those flags are basically immutable after the regexp object is created, why dont you build that string on object creation and just ask for it later? you could even build a lookup table with all possible strings and use that bitfield to index it. then you just can return a reference to the string and save on memory big time

[@GabrielSoldani]

Just curious, why not make object_get from C++ benefit from the cache instead? It’s probably even faster, and speeds up every call rather than just the ones on this specific built-in you’ve ported.

[@Bobbias]

That was my thought too. But still, performance isn't really the current top priority, and if it turns out in the future that this code ends up as a candidate for optimization in the future maybe it will eventually be rewritten in C++ with better optimizations. I think this was really just intended as an experiment (and something that would make for a good video).

[@kingkonefpv4553]

Thanks that was very amusing! i wrote a lot of js when node was new and you still had to use brains to make it run fast in the browser.

[@knobbymcfeck]

Don't those flags need to be left-shifted on creation, or in the enum? It's been ages since I did C++, so maybe I'm misunderstanding...?

[@awesomekling]

Oh yes, you are absolutely right! So the code was buggy. With that fixed, performance doesn’t change though :) Great observation dude!

[@knobbymcfeck]

@@awesomekling Woohoo! Thanks! For everything! I love these videos, thank you so much, tussentack!

[@pigalex]

here's another crazy idea you might consider: rewrite the UI (e.g the address bar area) in HTML. that would reduce dependence on Qt and would help with porting (could also make a desktop/tablet HTML UI and a mobile/vertical UI)

[@spiritofstar]

Yes, Firefox and Edge do it and they are relatively successful

[@Bobbias]

It makes perfect sense that avoiding the contains() should make best and worst case closer in speed. Unless I'm mistaken checking every flag would be O(nm) where n is the number of flags on the Regex and m is the number of flags to check against. Turning the flags into a bitmask would flatten this into O(m) since checking the bitmask is O(1) rather than contains() which is O(n).

[@Derrickasaur]

Swift vs Rust solved = just use JavaScript

[@ninadsachania3652]

Nice video, AK! Why did you change your OS from Linux to macOS? Just curious.

[@awesomekling]

I really missed the Instruments profiler, so I bought a MacBook Pro and started using it :)

[@ninadsachania3652]

@@awesomekling I also noticed that you started using a debugger instead of printf() debugging. What changed?

[@awesomekling]

Trying to use some new tools! But I still use printf debugging every day :)

[@su1cedek]

Thank you, I was missing your longer videos

[@Entarra]

Curious to know if the c++ version could also cache its work and be faster still

[@awesomekling]

There’s definitely ways to achieve that, but then we’d lose out on the comfy vibes of writing JS in JS! 😎

[@thislooksfun1]

I was wondering that too! That seems like it would have a more profound impact to me, but maybe there's some limitation as to why that's not easy to do. I might spend some time this weekend messing around with it though.

[@Entarra]

@@awesomekling Hah, well then by all means :)

[@jeffalonet]

just curious, in macos, how are you dragging the window from anywhere?

[@fredleckie5880]

Huzzah! A Stag beetle and a Scarab beetle?

[@msclrhd]

IIRC, both Mozilla and Google implement some of the JS functions in JavaScript.

[@awesomekling]

Yeah, WebKit as well. It does make a lot of sense :)

[@StevenHokins]

Very interesting, thank you for video of prototyping this

[@perotubinger]

I might totally missed this, but why couldn't you just use the flags substring and return that? And after you extracted the flags to a bit mask, couldn't you use that to make the native C++ accessor faster?

[@msclrhd]

The JavaScript spec specifies a flag order so if you say /foo/gi or /foo/ig then flags will return the same value in both cases. This is useful for checking in JS if two RegExp objects have the same flags, etc.

[@cxboog]

Because javascript is optimisation's worst enemy; that behaviour is required by the spec (also) because the user is allowed to subclass RegExp and override...almost everything, even the pattern string itself.

[@nordern1]

@@cxboog True, but it's fairly safe to assume that, most of the time, it will be invoked on a native RegEx object without overrides. Maybe there could be a fast path in that case?

[@perotubinger]

@@msclrhd ah, makes sense. That's what I meant by "I might have totally missed this" :)

[@cxboog]

@@nordern1 yeah there's tons of these optimisation opportunities!

[@JamesGroom]

Since there are only 8 flags, that means there are 256 possible string values, so can't you precompute those and use a LUT?

[@fritz1798]

WHF! Very interesting and hackish, love it!

[@Sosisoos]

Sorry for the off-topic question, but do you see yourself returning to Serenity sometime?

[@awesomekling]

Not anytime soon. I have a browser to build!

[@Oarix24]

@@awesomekling❤

[@FredClausen]

WHF!

[@awesomekling]

Well Hello Fred!

[@BrazilMentionedHueHue]

How has been your experience with copilot so far?

[@awesomekling]

Love it! Don’t think I’ll ever go back to programming without LLM autocomplete. So much less friction, especially when doing less interesting tasks. :)

[@XeZrunner]

It makes so much more sense to use LLMs as autocomplete helpers instead of fully writing entire files/classes/functions with them. After all, they're basically super good word/token predictors behind the curtains.

[@Siminfrance]

Wouldn't optimising the c++ code be more beneficial in the long run?

[@markbauermeister5449]

When I wanna "cache" something in my C++ game engine I just write it to an unordered map and load it back from there later. Not sure how accepted that is as a solution, since I'm not the most proficient C++ dev.

[@dennisheij8793]

Couldn't you use the flags enum to create the flags string from C++?

[@aiuno]

Hey! Haven't watched in a bit. When/why did you switch to Mac?

[@TheRealFallingFist]

I believe he was always on Mac, running SerenityOS in a VM. But he's put creating Serenity on hold, since he's focusing on the Ladybird browser exclusively right now.

[@TBasianeyes]

@@TheRealFallingFist Nah, he worked on Ubuntu for years. The latest Macs just compile so much faster than anything else so why wouldn't you use that.

[@charleyramm1]

I enjoyed that very much!

[@Tabonx_]

Where would I even start to learn this kind of wizardry? As an iOS dev, it all feels so foreign. I barely touch the terminal, and mixing languages, especially the way you did here, seems impossible to me.

[@awesomekling]

Try doing new things just outside your comfort zone every week :)

[@ferdynandkiepski5026]

And touching the terminal is quite useful. You could see how he forced himself away from lldb.

[@ferdynandkiepski5026]

Would the length of the regexp have an impact on the speed? I could see this being where JS gets slower. Your regexp was very short and quite sane. What people create with regexp isn't sane.

[@awesomekling]

The regular expression itself will still be evaluated by the same C++ regex engine we have. We're not implementing a regex engine in JS :)

[@doyouwantsli9680]

Js with good usage of sqlite is faster than c++ with poor usage of a db (especially a more bloated one)

[@ChillerDragon]

Catchy title hehe

[@alexander3293]

Doesn't V8 even have a "custom language" to do this?

[@aetube]

Well that's debatable

[@inukonet]

Why not just return the inner flags string?

[@inukonet]

Ah the flags property has a defined order and the input flags param can be in any order. Hm bizarre, returning the u32 flags to cpp should be faster still. Anyways, i like the idea od pushing stuff to js, as that makes you “dogfood” your js runtime and thus have (another) reason to make it fast.

[@GodlyBuTcheR]

Well Hello!

[@SachinDolta]

Good one

[@asphexor]

This is mad hacking video!

[@my_name_is_ahad]

I like your desktop wallpaper.

[@TheHanutaXD]

Wait, why does this video have so many dislikes? At least RYD thinks it is disliked :/

[@awesomekling]

This video currently has zero dislikes. Your extension is just showing you a random number :)

[@TheHanutaXD]

@@awesomeklinggood to hear :) seems like it is 50/50ing for some reason

[@TobyAsE120]

whk! js hacking, very fun!

[@ericdanielski4802]

Nice video.

[@nopair5688]

no way ?

[@underflowexception]

TIL: vim !$

[@ankk98]

!$ in bash refers to the last argument of the previous command. It's a quick way to reference and reuse the last parameter from your previous command.

[@Oarix24]

MORE OF SerenityOS PLZ

[@deckard5pegasus673]

I only watched until 7:00 but as soon as you said it was a problem with C not caching previous gets, I stopped the video. In those cases I do something similar this, and problem solved. I have a bit field to see if the get has been previously called, and another bit field to for the boolean get values. This is "old republic" C, if you don't like bit fields and bit manipulation, just use an array of booleans, or whatever, although it's less memory efficient. Maybe I should have watch the entire video, because maybe this isn't what you are looking for, but I didn't have time for an hour video today. bool getFlag(RegExpObject* regexp, const String& flagName) { static char FlagNames[][16] = { "global","ingoreCase", "multiline", "sticky", }; static int numFlags = sizeof(FlagNames) / sizeof(FlagNames[0]); static int RegExpFlags = 0 , RegExpCached = 0; for(int i=0; i> i) & 1)) { RegExpCached |= (1 get(flagName))) RegExpFlags |= (1 > i) & 1); } } printf("error not found"); return false; }

[@Bobbias]

Maybe you should have paid a bit more attention to what he was saying before you stopped the video, because it wasn't that the flags themself aren't cached. The issue is that a property access requires walking the prototype chain to find where the property actually exists, and in C++ there is no cache in the property lookup function, so they're forced to walk that chain every time. JS caches that part of the property lookup process. He also did use a bitfield to hold the actual flags because he discovered that the flags were being stored as a string and each lookup was calling contains() to search for each letter, but that was after moving to JS to take advantage of the property lookup caching.

[@glenfordwilliams5716]

WHF!

[@awesomekling]

Helllllooooo!!!