I have a major inconvenient using portable firefox. I don't know if everyone has the same lack. When I use it from my usb device it works intermitently... I mean with some seconds delay when I can't do anything, and then suddenly it works again. Is this normal???
As always, this is due to a slow flash drive or an extension that writes a bit of data (like the tab extensions with inefficient session saving). Please check the Firefox Portable support page for more information on other speed up methods.
Sometimes, the impossible can become possible, if you're awesome!
Yes, I have noticed the "pause" too. I downloaded ProcMon from Microsoft to monitor read/writes to the Flash drive. Apaprently, when I use the Portable version of FireFox the ProcMon utility reports "NAME COLLISION" results during a CreateFile operation that attempts to Create a file on the USB device.
I have followed all of the "Improving FireFox Portable's Performance" suggestions.
Running FireFox on the local PC (not on the USB device) CreatFile operations do not return the NAME COLLISION result. I have associated the "pause" to the NAME COLLISION return from CreateFile.
I have used PortableApps on two Windows XP SP-2 machines and one Windows 2000 Pro machine. I have an IBM T-30 Laptop with Windows XP SP-2 and USB 1.0 that has a "pause" issue with Portable FireFox. I have an Intel-based computer running Windows XP SP-2 that has a "pause" issue when running Portable FireFox. And I have an AMD-based workstation running Windows 2000 Pro that, while returns the NAME COLLISION message, does not have a "pause" problem.
Sorry I don't have an answer for you, but thought you might like to know you aren't the only one that noticed this "pause" issue.
Bradley Jennings
putting "knowledge" in "Teknowledgey".
I also noticed this but since changing my drive last night it works so much faster all comes down to drive speed was using an old ipod shuffle and it was really slow since changing to a new usb key it runs alot faster
Yes, I've tried numerous USB devices and multiple computer systems. The cause of the pause is still evident on any of these platforms. A faster storage medium only masks the root cause of the problem.
It seems that by running FireFox via the PortableApps NSIS-based executables there are numerous name collisions during calls to CreateFile. I noticed that running the FireFox or Thunderbird executables with the appropriate flags improves performance dramatically. This improved performance happens regardless of the storage medium.
Bradley Jennings
putting "knowledge" in "Teknowledgey".
Hi, BAJennings.
How do you identify name collisions--what tool(s) do you use, and are they portable ones? Is there some way I can verify or debunk that name collisions, whatever that means, are the cause of lengthy unresponsive periods in my Firefox sessions?
Also, you stated "I noticed that running the FireFox or Thunderbird executables with the appropriate flags improves performance dramatically. This improved performance happens regardless of the storage medium."
Pray, tell... what are "the appropriate flags"? Can ordinary users configure these through the user interface? I would assume so, but I've also no idea what you mean by appropriate.
I fully agree that a faster device masks the root of the problem, but I'd also like to know how to fix the problem when I'm already using fast devices. I would be deeply grateful for any advice or instructions you might wish to offer.
A very hopeful thank you in advance.
Cheers!
---Fox
He already said it: "Process Monitor". Google is your friend.
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx
It shows activity in Registry and filesystem. It can be quite useful at showing you what is happening behind the scenes. If you can catch it in the act of being bad, ProcMon can give you some very helpful information.
There's a bit of black magic in interpreting it correctly, but at least it can give you clues.
As for the flags, I think John is the expert on that. If you'd like to experiment, it isn't too difficult to make some changes to the "launcher" source code and compile it yourself, to see if you can come up with something that runs Firefox more efficiently for your needs. Of course, it you run into problems, it's not likely anyone can support the changes you make.
MC
"He already said it: "Process Monitor". Google is your friend."
Excuse me; obviously I missed that. I did use Google, but I looked for "name collision" and all I found were forum or blog entries asking about it. I wondered if what I already have (Process Explorer) might reveal name collisions, if I knew what to look for.
But thank you for the link! I see that Process Monitor labels the name collisions, so they are much easier than I thought they'd be to identify. And it does run portably; it's just an .exe file.
"As for the flags, I think John is the expert on that."
I was hoping John or another expert would be able to help.
"If you'd like to experiment, it isn't too difficult to make some changes to the "launcher" source code and compile it yourself, to see if you can come up with something that runs Firefox more efficiently for your needs."
I would like to experiment, but I don't have time to learn the programming language or firgure out everything I'd need to know or to have installed so I could accomplish that. I was a mainframe programmer, and am a technical writer now... I'm guessing that the coding and compiling method is a lot different than what I used to use, so I'd have to learn that first. After that, I'd still have to have time to experiment and see if I can come up with something that runs Firefox more efficiently for my needs.
"Of course, it you run into problems, it's not likely anyone can support the changes you make."
A very good reason to not go messing with something I know nothing about.
On another note, I'm not seeing any name collisions at all, now that I have Process Monitor up and running. And it's sitting there not adding any more process events; the last thing it did was create a thread (thread ID 3748), followed by nine Thread Exits, the last one being thread 3748.
...
It sat at that point for over 25 minutes, before it continued to the next event (RegQueryValue, HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind, resulting in buffer overflow). And now it's been sitting for an hour so far, after executing a CloseFile on noscript.jar. It seems there's a memory leak, also; my system keeps running out of available memory. I've shut down all unnecessary processes but whatever Firefox add-on is causing the problem is just taking up whatever memory is free.
Firefox was trying to run as well as it could around the memory issues, but I didn't know how to find out what was causing the leak... and I had to reboot the computer so I could use it.
EDIT
Wait... on another thread I started a few weeks ago about Firefox apparently losing its connections to settings (it seemed to start in safe mode) wsm23 offered this advice:
Try this first though, go to this folder and delete this file:
\PortableApps\FirefoxPortable\Data\profile\extendions.rdf
Relaunch FFPE.
I hadn't tried that in my current situation. Guess what? It worked. My Firefox fired right up, with all its extensions apparently intact. How could that be? What is that file for?
EDIT 2 -- UPDATE
Okay, that doesn't always work. What does seem to work is to not have PStart auto-run the files I would like it to auto-run. I have not had time to experiment with which program(s) might be causing the problem, but will post back when I do. Some of these programs have been updated since I first started noticing the problem, but I can't say which ones. I'll give current versions. The programs that PStart opens are Cryptainer 7.0.3, ClipGuru 2.0, Yadabytes SubText (although I did disable that one and try to start Firefox, so I think we can rule it out), and Process Explorer 10.21.0.0.
Cheers!
---Fox