You are here

[Fixed] FirefoxPortable.exe higher disk access in recent builds

16 posts / 0 new
Last post
Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
[Fixed] FirefoxPortable.exe higher disk access in recent builds

FirefoxPortable.exe burden HDD only after reload Firefox.
If you close Firefox and restart, then it's okay.
http://ipic.su/img/img7/fs/kiss_4kb.1467032652.png
So in fact there shouldn't be !? Sad
Fix please!
(Win7x32 , Firefox 47)

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Incorrect

FirefoxPortable.exe only accesses the disk before and after running firefox.exe. It does this to adjust paths in the profile and then clean a couple things up after exit. It does nothing at all disk-wise while Firefox is running. Literally nothing disk-wise.

You can look at the code yourself. It just sits there and waits for Firefox to close.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
Incorrect

Why so soon be expressed "Incorrect" ?!
The problem exists, and here's the proof :

I check the version: 46,45,44,43 - burden HDD :evil:
Version 42 - OK !
I replaced the FirefoxPortable.exe 42 >>> 47 - OK !

i.e., as i understand it, this has something to do with the choice of the bitness.
Fix please !

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Can't Reproduce

I can't reproduce this on 64-bit or 32-bit Windows. After Firefox is up and running, FirefoxPortable.exe sits there doing nothing with 0 I/O Reads/Writes/Other and 0 I/O Read/Write/Other Bytes, just as always. The only change in the 43.0 launcher was to detect whether the OS was running 64-bit before launch and then launch the correct version of Firefox. The code while running is the exact same 6 lines as it's been for years.

For completeness, do you have any custom settings in FirefoxPortable.ini? What app are you using to map the the disk use? Are you running any extensions that could cause Firefox to restart itself?

The only thing I can think of is if you somehow triggered something that would escape the ExecWait (firefox.exe restarting itself) and cause it to fall back to firefox.exe check for running every 2 seconds. But there's nothing I can think of that would work one way with the pre-64-bit launcher and one way post.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
good

FirefoxPortable.exe burden HDD only after reload Firefox.

(I downloaded the clear builds and immediately checked them)

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Questions

Please answer the questions in the above post.

Additionally, it's almost no burden if it needs to do the fallback check every 2 seconds. It's a single load of a single 4K DLL from the local hard drive's TEMP directory. And it's almost definitely cached in memory.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
OK

I downloaded a clean build, install any addon require a reboot and rebooted.

Please note that when I replace FirefoxPortable.exe of version 42, the disk accesses are not observed.

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Again

Once again, please answer ALL the above questions before posting again.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
What app are you using to map

What app are you using to map the the disk use?

I do not understand what it is. Nothing to use.

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Screenshot

The screenshot you showed above. What is it from? I wanted to reproduce it exactly. Though I'll need to somehow trigger a firefox.exe restart as that should normally not happen.

And, PLEASE, again, answer all the above questions.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
:)

Yes, then I guess what you mean.. Process Hacker v2.39
Here's another http://ipic.su/img/img7/fs/kiss_5kb.1467129458.png
On other issues, I have already given the answer :
" I downloaded a clean build, install any addon require a reboot and rebooted. "

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Ah Ok, That Helps

Ah ok, that helps. In Task Manager, it made almost no difference between them. In Process Hacker, it shows a clearer difference.

It seems that the FindProcDLL included in NSIS Portable 2.46 Rev 2 is different compared to the one in the NSIS Portable 2.46 Rev 3 release. That's what changed between Firefox 42 and Firefox 43. Nothing in our code changed, which is what made this make no sense. I believe the newer one works with 64-bit processes while the older does not. I'm investigating further.

Sometimes, the impossible can become possible, if you're awesome!

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Figured It Out

Ok, it seems that the newer version of the FindProcDLL plugin has a higher cost to doing a process check in terms of disk use. We can't revert to the old version used in NSIS 2.46 Rev 2 because that one only works with 32-bit processes and won't work with dual mode apps like Firefox Portable on 64-bit machines (the majority of users). But, this new FindProcDLL plugin does introduce a new method allowing for a low cost wait for a process to finish that won't consume CPU or disk. So, I've updated the Firefox Portable launcher to make use of that. Each time firefox.exe restarts there will be a single check on the process and then a wait, so you won't see the spike every 2 seconds. firefox.exe restarts rarely so this will reduce the overall cost of the launcher in terms of CPU and disk compared to the old one.

This change is included in Firefox Portable 47.0.1 which is building now.

Sometimes, the impossible can become possible, if you're awesome!

Romardan
Offline
Last seen: 8 years 3 months ago
Joined: 2015-05-16 09:02
Thank you !

Thank you !
Let's hope for the best.
And I have already implemented auto-kill FP.exe after starting Firefox Smile

(My Firefox is on a stationary PC, just like when everything in the same folder on the D:)

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 6 days 16 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
Don't auto-kill

Don't auto-kill FirefoxPortable.exe - this is what manages the portability. Just wait for the update to be pushed out.

John T. Haller
John T. Haller's picture
Online
Last seen: 14 min 56 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Fixed in Firefox Portable 47.0.1

This is fixed in Firefox Portable 47.0.1 posted today. The new launcher will filter out to ESR, Beta, and Dev as they are released as well. You can replace any of their launchers with this one if you'd like the benefit today. This only affects slightly higher disk access after firefox.exe is restarted (not an everyday thing).

I'll be adding this same setup to the Thunderbird launcher and PAL itself in later releases.

UPDATE: Fixed in Thunderbird Portable 45.2.0

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments