Start-up time until menu is actually being displayed: 2'19" Start-up time until menu is actually being displayed: 3'12" Works as expected, including the possible and known 100%-issue and causes. Stability: not relevant and not tested, doing anything may result in a Microsoft Harddisk Torture- and/or disk-full-related crash anyway.ĬPU load: ~100%, responsive, may have been 2-6%'ish before the add-on update. Start-up time until (file open) menu is actually being displayed: 3'34" Updated add-on, no updated langpack to save a few hours, no changes (AdBlock Plus, ChatZilla) because the CPU load is not that relevant: ![]() SM 2.42, r3, second time to account for initial profile checks. Start-up time until menu is actually being displayed: 3'10"ĬPU load: not that relevant, no improvements expected, almost anything is acceptable IBM ThinkPad 600E, Pentium II, CPU 500 MHz, RAM 224 (expected: above 256!?) MiB: Grab a dual core machine, visit YouTube, and smile when the difference is that CPU load peaks have dropped from a honest 100% to 98%. no video tests, due to a lack of relevancy. Installing two different FF versions is possible, packaged and installed, but there's no way to solve the disk full-errors of that route. (Update: that -O3 build failed to terminate when I closed it and left the WPS unresponsive - had to kill it.)Ī FF45 for i686+ would be nice-to-have. I'll keep testing but my initial impression is that -Os is a noticeably weaker performer than the others. I'm posting this using the -O3 build, and after watching several Sam Smith videos, one core keeps spiking to 100% every few seconds. Of course, there's only so much that mere optimization tweaks can fix. ![]() Using the -O3 version, I was surprised to find that VPX put less of a strain on my quad-core than h264 - but both performed well. Certainly there were some dropped frames with both HTML5/H264 and WEBM/VPX, but only once did the browser become momentarily unresponsive (I think it was with -Os and VPX). Let me tell you, regardless of which build I tried, this was the best YouTube experience I've ever had. My first stop for each was YouTube - a site I seldom use because I can only take so much frustration. I d/l'd all 3 as soon as I saw this post and put icons for each on my Desktop so I could test them side-by-side. and will build for other CPU's.įirst off, let me thank you for your responsiveness. I'll probably delete the exp builds so if anyone wants to save them. There's also a build of Thunderbird with straight -O3 optimization that I'm using, If requested, I can build with different optimizations. Firefox built with this often had a timing issue and failed to play Youtube videos, getting stuck at the loading phase. May be the most stable but worst performing. Rich pointed out that using -O3 is likely to expose GCC bugs, so I also built one using straight -O2, which is what we traditionally used until late in the 10ESR cycle. ![]() This is also what other platforms such as Linux use, xul.dll is almost 10 MB smaller. This one is built the same as the latest Firefox, with the JavaScript engine using -O3 and the rest using -Os for minimal size. This one is built with straight -O3 optimization, should be the fastest, also the most memory use i686 is the minimum requirement as Mozilla uses some atomic instructions that are not available in earlier CPU's. Each is built with different optimizations, curious what works best for people.Īll target i686 for now. So I've built 3 SeaMonkey packages based on the latest (and probably last) code from Bitwise.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |