Firefox does not handle large bookmark "files" gracefully, it HANGS

Question

Essentially large #'s ( massive ) cause Firefox to go off the deep end and never shut down in any reasonable time. I tried backups in JSON and HTML, files produced took ~2-3 days, 50mbyte and ~90mbytes each. Essentially when you exceed past some indeterminate bookmarks "size" Firefox never gracefully in some useful time frame shut down, folks here have said when firefox is attempted shutdown and if it does not, then go to task manager and shut the Firefox process. THat is less desireable. Question is when firefox closes, ( request to shutdown ) is it trying to do a whole host of task cleaning ./ bookmarks backup? I tried cutting back my books marks slightly, now FF can be closed without Taskmanager shutdown, but now none of my addons ( that I disabled and deleted some ) none seem to restart ( Firefox seems to thrash CPU utilization from near zero, to ~100% via trying to restart NoScript, and pounds away for many minutes, until I say this is not good ).
I have Vista Business 32, configured to work well latest FF 26.0.
Chrome ( SR Ironware Iron browser ) that I have zero bookmarks runs fine, I need FF to work reconfigured without a reinstall due to all the passwords I have loaded into the FF over time.
GIven that a minor ?10-20% reduction in Bookmarks that took me a few hours to do, returns the ability to not have to go to taskmanager to brutally shut the FF task when an exit from FF does not remove it and it s large memory footprint, and now mostly does, with minor reduction of a massive bookmarks set, this is weird. FF never exceeds my win 32 memory, largest footprint I had I think was ~1gb in memory from lots of web pages.
But presently I cannot seem to restart Noscript... which is troubling

Answer 1

I am not a software engineer, merely a user, I am not asking for help for me to personally fix what is a fundamentally a product software problem.
I'd also point out that in addition to Hanging in backups, 3 days actually of FF running the bookmarks backup that produced 50mb JSON file and 90 mb HTML backup file, after 1/2 day respite of actually being able to have firefox close on user exiting after i completed the backup and reduced bookmarks slightly ( ~10% deleted ), now it is back to its usual self, taking forever to shut down, looking like a memory hog monster with >0.5 GB ram footprint, and often grows upon exit that the program persists in Task Manager Process List ad nauseum, till a manual task manager forced shutdown.
A user ( not a software coder ) should not have to twiddle with arcane settings buried in some obscure file undocumented, to avoid having a program hog their machine for 3 days just to backup Bookmarks manually ( meaning the code in the bookmarks backup procedure is coded rather inefficiently when scaled to large # of bookmarks ),
and I suspect FF shutdown internal procedure similarly does some rather inefficient logging to needlessly find grained writing to files on disk upon request by user to EXIT ( hopefully shut in reasonable time to free the dual core CPUs from ?50-100% utilization for days to backup / save stuff I could care not enough to wait for days for backup completion.
If RAM was used to assemble the backup in memory entirely, then to enable doing a small series of long serial block writes to disk, I suspect this all might go smoother than what appear to be a huge series of small writes to the disk as present it seems.
Possibly less sensible at present, and I can tell this by watching the disk activity light slowly flashing and Task Manager CPU activity spiking 100% and dropping regularly ( at high frequency ) for hours or days in the case of manual backup.
Load ALL the data to RAM instead and do one large sequential write ( sort of obvious for performance of the code and avoiding days to backup bookmarks ? ) There is plenty of room to load the JSON or HTML directly all to ram, and massage, and dump in one long faster sequential write to disk? Or am I missing something?
The justifications explained are almost silly, as I merely want to use FF, not make a career of learning undocumented buried feature settings. I have better things to do with my time, and I will remark the issues I describe might not be unique to FF's browser, it might also be common on other broswers ( I do not know, but I will be gracious enough to say so ).
Granted the program is free, but memory and task management efficiency is mediocre for truly heavy users. I read a lot and have sometimes 100 tabs open, the manner this is handled with FF sometimes brings a dual core CPU in Win Vista ( optimized via reg settings recommended in deeper articles about VIsta to be more XP like in operation ) to its knees.
This reminds me of the creeping featurization of GMAIL where originally GMAIL was fast and efficient, impressively so, FF might not properly vet ADDONS for good memory and shut down behavior and might consider doing so, to block those which affect stable operation, from being downloaded, as might actually testing / validating the safety & security & privacy of some addons ( rather than presently leaving to unsophisticated users to do so haphazardly ).
just some obvious observations.
It should not take common users to fiddle with undocumented obscure features ( hidden settings in undocumented files ) to make a quality product ( FF is good ) run properly. There is something to think about here.