Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275524 > unrolled thread

Re: Firefox alternatives?

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Firefox alternatives? "Paul M. Foster" <paulf@quillandmouse.com> - 2024-12-11 22:10 +0100
    Re: Firefox alternatives? Bret Busby <bret@busby.net> - 2024-12-11 22:20 +0100
      Re: Firefox alternatives? Greg Wooledge <greg@wooledge.org> - 2024-12-12 00:10 +0100
        Re: Firefox alternatives? Jeffrey Walton <noloader@gmail.com> - 2024-12-12 01:00 +0100
        Re: Firefox alternatives? "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-12 19:20 +0100
          Re: Firefox alternatives? Greg Wooledge <greg@wooledge.org> - 2024-12-12 19:30 +0100
            Re: Firefox alternatives? Nicolas George <george@nsup.org> - 2024-12-12 23:20 +0100
              Re: Firefox alternatives? Nicolas George <george@nsup.org> - 2024-12-13 08:50 +0100
            Re: Firefox alternatives? jeremy ardley <jeremy.ardley@gmail.com> - 2024-12-13 01:10 +0100
              Re: Firefox alternatives? George at Clug <Clug@goproject.info> - 2024-12-13 02:20 +0100
    Re: Firefox alternatives? Jan Claeys <lists@janc.be> - 2024-12-13 17:00 +0100
      Re: Firefox alternatives? Bret Busby <bret@busby.net> - 2024-12-13 23:10 +0100
      Re: Firefox alternatives? Jan Claeys <lists@janc.be> - 2024-12-14 00:00 +0100
    Re: Firefox alternatives? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-13 17:10 +0100

#275524 — Re: Firefox alternatives?

On 12/11/24 15:08, Van Snyder wrote:
> After Firefox has been running for a few days my Debian 12.5 gets 
> really slow. The mouse jerks when it works at all. It takes a minute 
> or two for wndows to close or top. At the moment, Firefox has 19 
> processes running. Memory is half full, and swap is about 10% used. 
> When I kill Firefox and restart, things go back to normal for a few hours.
>
> What alternatives that aren't such pigs do you recommend?
>
I call this "memory leakage". I don't know if actual code bugs, or the 
sloppy way Firefox allocates and frees memory. As far as I know, all 
browsers suffer from this. If you find one which doesn't, let us know.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [next] | [standalone]

#275526

On 12/12/24 04:50, Paul M. Foster wrote:
> On 12/11/24 15:08, Van Snyder wrote:
>> After Firefox has been running for a few days my Debian 12.5 gets 
>> really slow. The mouse jerks when it works at all. It takes a minute 
>> or two for wndows to close or top. At the moment, Firefox has 19 
>> processes running. Memory is half full, and swap is about 10% used. 
>> When I kill Firefox and restart, things go back to normal for a few 
>> hours.
>>
>> What alternatives that aren't such pigs do you recommend?
>>
> I call this "memory leakage". I don't know if actual code bugs, or the 
> sloppy way Firefox allocates and frees memory. As far as I know, all 
> browsers suffer from this. If you find one which doesn't, let us know.
> 
> Paul
> 

Many years ago, I believe when I was being taught 'C' programming, we 
were taught to use two instructions named malloc and (I believe the 
other important corresponding instruction), dealloc, and, some software, 
including some web browsers (and, the vile javascript) seem to disregard 
that instruction and its importance, which is kind of like running an 
internal combustion engine without a governor, or, parking a vehicle on 
a slope, without engaging the handbrake.

Memory leakage, by its wording, appears to indicate that the memory gets 
freed, by leakage (like diarrhoea or incontinence), whereas, what seems 
to be occurring, is more like constipation, where the contents are not 
being freed, cumulatively increasing the pressure, causing the computer 
to not feel well, and "fall over".


..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[toc] | [prev] | [next] | [standalone]

#275538

On Thu, Dec 12, 2024 at 05:17:46 +0800, Bret Busby wrote:
> Many years ago, I believe when I was being taught 'C' programming, we were
> taught to use two instructions named malloc and (I believe the other
> important corresponding instruction), dealloc, [...]

The opposite of malloc() is free().

> and, some software, including
> some web browsers (and, the vile javascript) seem to disregard that
> instruction and its importance, which is kind of like running an internal
> combustion engine without a governor, or, parking a vehicle on a slope,
> without engaging the handbrake.

These programs aren't written in C.  Manual memory management is a dying
art.  Most languages these days use automatic garbage collection, freeing
unused memory when nothing is using it any longer.

This makes memory leaks less common, but when they *do* occur, they're
quite difficult to find.  Usually it means you've accidentally retained
a reference to the object in question in some part of the program that
never goes away.

[toc] | [prev] | [next] | [standalone]

#275541

On Wed, Dec 11, 2024 at 6:01 PM Greg Wooledge <greg@wooledge.org> wrote:
>
> On Thu, Dec 12, 2024 at 05:17:46 +0800, Bret Busby wrote:
> > Many years ago, I believe when I was being taught 'C' programming, we were
> > taught to use two instructions named malloc and (I believe the other
> > important corresponding instruction), dealloc, [...]
>
> The opposite of malloc() is free().
>
> > and, some software, including
> > some web browsers (and, the vile javascript) seem to disregard that
> > instruction and its importance, which is kind of like running an internal
> > combustion engine without a governor, or, parking a vehicle on a slope,
> > without engaging the handbrake.
>
> These programs aren't written in C.  Manual memory management is a dying
> art.  Most languages these days use automatic garbage collection, freeing
> unused memory when nothing is using it any longer.
>
> This makes memory leaks less common, but when they *do* occur, they're
> quite difficult to find.  Usually it means you've accidentally retained
> a reference to the object in question in some part of the program that
> never goes away.

The thing that strikes me about the managed languages, like Java and
.Net, are the number of memory leak tools you have to use to find the
leaks that are supposed to be automatically handled for the
programmer...

Jeff

[toc] | [prev] | [next] | [standalone]

#275596

On Wednesday 11 December 2024 06:00:37 pm Greg Wooledge wrote:
> > and, some software, including
> > some web browsers (and, the vile javascript) seem to disregard that
> > instruction and its importance, which is kind of like running an internal
> > combustion engine without a governor, or, parking a vehicle on a slope,
> > without engaging the handbrake.
> 
> These programs aren't written in C.  Manual memory management is a dying
> art.  Most languages these days use automatic garbage collection, freeing
> unused memory when nothing is using it any longer.
> 
> This makes memory leaks less common, but when they *do* occur, they're
> quite difficult to find.  Usually it means you've accidentally retained
> a reference to the object in question in some part of the program that
> never goes away.

I'd really love it if firefox didn't consume increasing amounts of memory as time went on...

Why would it do that?  That's been the case for a long time  over many versions.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

[toc] | [prev] | [next] | [standalone]

#275599

On Thu, Dec 12, 2024 at 13:20:28 -0500, Roy J. Tellason, Sr. wrote:
> On Wednesday 11 December 2024 06:00:37 pm Greg Wooledge wrote:
> > This makes memory leaks less common, but when they *do* occur, they're
> > quite difficult to find.  Usually it means you've accidentally retained
> > a reference to the object in question in some part of the program that
> > never goes away.
> 
> I'd really love it if firefox didn't consume increasing amounts of memory as time went on...
> 
> Why would it do that?  That's been the case for a long time  over many versions.

Because finding and fixing memory leaks is *really difficult*.  And not
much fun.  And doesn't let you put fancy new blurbs on your "what's new"
page.

[toc] | [prev] | [next] | [standalone]

#275612

Van Snyder (12024-12-12):
> Some languages have dynamic-memory facilities that inherently do not
> leak, unless you are intentionally careless.

There is nothing more careless in adding an element to a hash table and
forgetting to remove it than in malloc()ing a memory area and forgetting
to free()it.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#275625

Van Snyder (12024-12-12):
> > There is nothing more careless in adding an element to a hash table
> > and
> > forgetting to remove it than in malloc()ing a memory area and
> > forgetting
> > to free()it.
> In languages that inherently do not leak (unless you are intentionally
> careless)

Saying it in a simpler way: there is no such thing.

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#275613

On 13/12/24 05:56, Van Snyder wrote:
>>
>> Because finding and fixing memory leaks is *really difficult*.  And not
>> much fun.  And doesn't let you put fancy new blurbs on your "what's new"
>> page.
> 
> Some languages have dynamic-memory facilities that inherently do not 
> leak, unless you are intentionally careless. But C and C++ are not in 
> that set.

C++ has a methodology called Resource Management. It's not at all 
difficult to do and means you will not get resource leaks (memory usually)

Using the Resource Management methodology means major software 
applications can be written in C++ to be fast and reliable - unlike the 
unmitigated crap that is java and dot net that are neither fast, nor 
reliable, nor write-once run anywhere.

This is why just about every browser is written in C++ and not in java 
or dot net.

AI application similarly are written as C++/C core libraries with an 
optional veneer of python for those who are so inclined.

[toc] | [prev] | [next] | [standalone]

#275615

On Friday, 13-12-2024 at 11:03 jeremy ardley wrote:
> 
> 
> On 13/12/24 05:56, Van Snyder wrote:
> >>
> >> Because finding and fixing memory leaks is *really difficult*.  And not
> >> much fun.  And doesn't let you put fancy new blurbs on your "what's new"
> >> page.
> > 
> > Some languages have dynamic-memory facilities that inherently do not 
> > leak, unless you are intentionally careless. But C and C++ are not in 
> > that set.
> 
> C++ has a methodology called Resource Management. It's not at all 
> difficult to do and means you will not get resource leaks (memory usually)
> 
> Using the Resource Management methodology means major software 
> applications can be written in C++ to be fast and reliable - unlike the 
> unmitigated crap that is java and dot net that are neither fast, nor 
> reliable, nor write-once run anywhere.
> 
> This is why just about every browser is written in C++ and not in java 
> or dot net.
> 
> AI application similarly are written as C++/C core libraries with an 
> optional veneer of python for those who are so inclined.
> 
>

+1

 

[toc] | [prev] | [next] | [standalone]

#275647

On Wed, 2024-12-11 at 15:50 -0500, Paul M. Foster wrote:
> I call this "memory leakage". I don't know if actual code bugs, or
> the sloppy way Firefox allocates and frees memory. As far as I know,
> all browsers suffer from this. If you find one which doesn't, let us
> know.

It's not only memory leaks but also memory fragmentation that will make
memory usage grow, which is a lot harder to prevent...

And in case of a browser, it's not only the browser itself that can
leak memory, but also the JavaScript programs that run on it.  I've
seen cases where force-reloading (Ctrl+F5) or closing one page that had
been loaded in a tab for a while, and then waiting a couple minutes to
give the JavaScript engine's garbage collector time to do its job,
freed about 8 GiB (!) of RAM afterwards...


-- 
Jan Claeys

(please don't CC me when replying to the list)

[toc] | [prev] | [next] | [standalone]

#275670

On 14/12/24 05:54, Van Snyder wrote:
> On Fri, 2024-12-13 at 16:54 +0100, Jan Claeys wrote:
>> I've
>> seen cases where force-reloading (Ctrl+F5) or closing one page that had
>> been loaded in a tab for a while, and then waiting a couple minutes to
>> give the JavaScript engine's garbage collector time to do its job,
>> freed about 8 GiB (!) of RAM afterwards...
> 
> Is there a menu item to force reload?
> 
> Ctrl+F5 on KDE is "switch to desktop 5."
> 
Try <CTRL><R> .

Works in Firefox on MATE DE.

I have not previous been aware of <CTRL><F5>.

I have been aware of <SHIFT><F5>, for reloading/refreshing and clearing 
cache, but, that now has a different effect in Firefox.

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[toc] | [prev] | [next] | [standalone]

#275671

On Fri, 2024-12-13 at 13:54 -0800, Van Snyder wrote:
> On Fri, 2024-12-13 at 16:54 +0100, Jan Claeys wrote:
> > I've seen cases where force-reloading (Ctrl+F5) or closing one page
> > that had been loaded in a tab for a while, and then waiting a
> > couple minutes to give the JavaScript engine's garbage collector
> > time to do its job, freed about 8 GiB (!) of RAM afterwards...
> 
> Is there a menu item to force reload?
> 
> Ctrl+F5 on KDE is "switch to desktop 5."
> 

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_navigation
https://support.mozilla.org/en-US/kb/mouse-shortcuts-perform-common-tasks#w_navigation

So Ctrl+Shift+R and holding down Shift while clicking the refresh
button should do the same.


In fact, a simple F5 or Ctrl+R might be enough in most cases.


-- 
Jan Claeys

(please don't CC me when replying to the list)

[toc] | [prev] | [next] | [standalone]

#275648

> I call this "memory leakage". I don't know if actual code bugs, or the
> sloppy way Firefox allocates and frees memory. As far as I know, all
> browsers suffer from this. If you find one which doesn't, let us know.

It doesn't have to be a leak in the browser's code.  It can also be
a leak in the Javascript code that the user (well: the remote sites
that the user visits) asks the browser to run.


        Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web