Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering code quality in Firefox

hacks.mozilla.org

Post reply on HN
Print view View original

141–150 of 155 posts

Re: Engineering code quality in Firefox

#141

Post by hafta »

mschuetz wrote: post #92
bergheim wrote: post #49

I just wanted to say that, despite a few mishaps, firefox is what _everybody_ on hn should be using. I can give my browser-time credentials, but really. Firefox is amazing. Care for the open web, fear ie6, and at the same time enjoy firefox!

I wish I could recommend Firefox but I can't because it cripples performance of the things I'm working on, namely streaming and rendering large 3D data. I'm using Firefox privately at home but for work, including work@home, I'm using almost exclusively Chrome. Chrome is just so much faster and the developer tools so much more polished than Firefox. DataView is 40 times slower in Firefox, and I'm using it quite extens…

Would you be able to file a Firefox bug on the DataView problem? Or if you have an example link we could look at that would be greatly appreciated.

Re: Engineering code quality in Firefox

#142

Post by mschuetz »

hafta wrote: post #141
mschuetz wrote: post #92

Earlier quoted context omitted.

I wish I could recommend Firefox but I can't because it cripples performance of the things I'm working on, namely streaming and rendering large 3D data. I'm using Firefox privately at home but for work, including work@home, I'm using almost exclusively Chrome. Chrome is just so much faster and the developer tools so much more polished than Firefox. DataView is 40 times slower in Firefox, and I'm using it quite extens…

Would you be able to file a Firefox bug on the DataView problem? Or if you have an example link we could look at that would be greatly appreciated.

There is this 6 year old and open report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1065894

Chrome has improved DataView 2 years ago: https://v8.dev/blog/dataview

A rather basic jsperf is here: https://jsperf.com/dataview-float-int The results are that the u8 hack is equally slow in firefox and chrome (~90ops/sec), the DataView version is 10x faster in chrome(945ops/sec) but almost 4x slower in firefox(25ops/sec).

Re: Engineering code quality in Firefox

#143

Post by Epskampie »

skohan wrote: post #106
Epskampie wrote: post #86

Earlier quoted context omitted.

> a set of standards for handling code from an arbitrary source securely That is what html+js is. Why do you presume a different standard would be more efficient in the end?

HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist. The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very lim…

But if it were to run on every platform and processor the binary would have to be written to some VM, which would slow it down a bit. That’s webassembly, which is coming up.

Also, there would have to be some GUI framework that works well across all devices, phone to desktop. That alone would be massive undertaking.

I agree there is no technical reason, but once you consider all limitations and let some time pass in the end you might up with something similar to what we have now. For example you might standardize on a current graphics API, but in a few years: guess what, you have an outdated API like webGL now.

Re: Engineering code quality in Firefox

#144

Post by rataata_jr »

dontbenebby wrote: post #79
alephnan wrote: post #23

We had an "open-ended" project in an undergraduate Computer Security course to discover a 0-day in Firefox. The professor (a researcher, not lecturer, by trade) didn't really have a curriculum, and said this artifact accounted for 70-80% of our grade. Trying to compile Firefox was already a challenge. That, and each compile took an hour. IIRC, Firefox is built on some esoteric architecture / design pattern that's def…

You can’t arbitrarily change the syllabus to a student’s detriment. I’d have argued up the chain.

Where exactly does that end well for the student?

Re: Engineering code quality in Firefox

#145

Post by skohan »

Epskampie wrote: post #143
skohan wrote: post #106

Earlier quoted context omitted.

HTML+ECMAScript keeps the developer at quite a distance from the hardware, and it imposes all kinds of limitations which don't have to exist. The web is good enough for pure content delivery, but for more advanced interactive applications, the limitations are a huge waste. For instance, I have a computer at home with a 12-core, 24-thread processor, but web applications are basically single-threaded with some very lim…

But if it were to run on every platform and processor the binary would have to be written to some VM, which would slow it down a bit. That’s webassembly, which is coming up. Also, there would have to be some GUI framework that works well across all devices, phone to desktop. That alone would be massive undertaking. I agree there is no technical reason, but once you consider all limitations and let some time pass in t…

> But if it were to run on every platform and processor the binary would have to be written to some VM

Not necessarily. You could have different binaries for different architectures. All you need is a consistent system interface with a well-specified ABI, and the client would just have to request the binary for their architecture.

> That’s webassembly, which is coming up.

Web assembly still has the limitations of running inside the browser. It's still single-threaded, and also the file size is pretty large compared to a binary.

> Also, there would have to be some GUI framework that works well across all devices, phone to desktop.

If you had a consistent system interface, you'd only have to do it once.

> For example you might standardize on a current graphics API

I mean Vulkan is basically this. And graphics API's are converging not diverging: modern graphics API's are all structured in a very similar way, since they're all just wrappers around the low level functionality of the GPU at this point.

I'm not saying it would be easy, but the reasons we don't have it have more to do with the fact that it would be difficult to get buy-in from OS vendors than it has to do with the technical problems involved. From a technical perspective, we could easily do way better than modern web.

Re: Engineering code quality in Firefox

#146

Post by totony »

alephnan wrote: post #23

We had an "open-ended" project in an undergraduate Computer Security course to discover a 0-day in Firefox. The professor (a researcher, not lecturer, by trade) didn't really have a curriculum, and said this artifact accounted for 70-80% of our grade. Trying to compile Firefox was already a challenge. That, and each compile took an hour. IIRC, Firefox is built on some esoteric architecture / design pattern that's def…

Whenever you have trouble compiling something, just look at how gentoo approaches it. They're the last bastion making sure OSS is actually buildable.

Them are their users most likely are the #1 source of build documentation, bug reports and fixes in OSS

Re: Engineering code quality in Firefox

#147

Post by happosai »

swiley wrote: post #118
thayne wrote: post #66

Earlier quoted context omitted.

> Trying to compile Firefox was already a challenge. That, and each compile took an hour. At first glance, this sounds terrible. But when compared to software projects of comparable size, Firefox is hardly unique. Compare to compiling Chromium for example, or even the Linux kernel.

Those are all very different levels of difficulty IMO: Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies. Firefox is pretty painful but it's doable with a decent amount of care and bandwidth. Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are al…

Nah building is fine, just follow the steps from Debian/Ubuntu/whateverdistro . But trying to contribute is fun. By the time you've danced all the hoops to allow you to contribute, some Google employee has already refactored the code around the bug. Then you have to be fast enough to get your updated patch applied before someone else has reorganized the code again...

At some point I started wondering if indeed I'd get the fix in faster by starting to practice whiteboard interviews.

Re: Engineering code quality in Firefox

#148

Post by tedmielczarek »

jbroman wrote: post #138
freeboson wrote: post #136

Earlier quoted context omitted.

Do you have to build chromium with blaze? Or does it use e.g. cmake or something?

It's uses gn, a build system developed for Chromium. That said, on an Ubuntu system the steps to build Chromium are fairly well-documented and straightforward, as long as you have an appropriately beefy system (unfortunately it's a long wait and a fair amount of RAM is required, and Googlers tend to use a distributed build system). https://chromium.googlesource.com/chromium/src/+/master/docs...

gn is of course a meta-build system, the initials stand for "generate ninja". ninja does the actual build execution. The Firefox build system has a similar homegrown frontend called mozbuild, which generates Makefiles for the actual build.

Re: Engineering code quality in Firefox

#149

Post by hafta »

mschuetz wrote: post #142
hafta wrote: post #141

Earlier quoted context omitted.

Would you be able to file a Firefox bug on the DataView problem? Or if you have an example link we could look at that would be greatly appreciated.

There is this 6 year old and open report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1065894 Chrome has improved DataView 2 years ago: https://v8.dev/blog/dataview A rather basic jsperf is here: https://jsperf.com/dataview-float-int The results are that the u8 hack is equally slow in firefox and chrome (~90ops/sec), the DataView version is 10x faster in chrome(945ops/sec) but almost 4x slower in firefox(25ops/…

Thanks.

Re: Engineering code quality in Firefox

#150

Post by why_only_15 »

pcwalton wrote: post #132
gsnedders wrote: post #119

Earlier quoted context omitted.

I'm unaware of any special treatment (but that doesn't mean there is none!), beyond Apple caring about battery life in general on their OS and I would strongly expect that the browser forms part typical-use testing of the OS and as such influences what parts get targeted for performance work. Certainly Apple's WebKit port uses Core Animation heavily, which is definitely heavily tied to the compositor in the window se…

Safari definitely uses private APIs (or at least did at one point) to manipulate out-of-process layers more directly than the public CA API lets you do.

Hey, I've been trying to remember something about the way CA and the windowserver interact for a few weeks but I can't find anything about it. I remember somewhere there was a setting for maybe the backing layer of how a window was set up? And there were a few hidden ones? i remember that one of these settings was how minimized windows were implemented because the layer was set up to copy some other layer, and then shrunken, so that way you get minimized windows changing when the window changes for free.
Post reply on HN