It doesn't. Firefox manages it's memory exactly the way it wants to; by caching the back button.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru' MacDonald Sent: Sunday, 1 June 2008 11:12 AM To: 'Discussion of Half-Life Programming' Subject: Re: [hlcoders] CUtlVector<*>... Memory management? I thought FireFox could do no wrong? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, May 31, 2008 8:32 PM To: [email protected] Subject: Re: [hlcoders] CUtlVector<*>... Memory management? There are only a few sections where the gains were at all significant. Rather than a divergent library they probably could've realized a few optimization patches and gotten the same benefit. The thing I don't understand though is why so many software companies to this day still try to do so much low-level memory management themselves, as if the OS was incapable of it. It's not just gaming software either: case in point, Firefox and its insane memory management that bloats to using hundreds of megabytes over time. Paul Peloski wrote: > -- > [ Picked text/plain from multipart/alternative ] > In the algorithms they made some significant gains on Windows and Xbox, but > not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's > STL implementation. Since a lot of games will target Microsoft platforms I > guess it was a good move to rewrite their STL implementation. > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > equivalent operations using STL. > > Regards, > > Paul > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > > >> That is a really interesting article. How did you find it? >> >> Also, they do have some performance benchmarks buried at the bottom: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_ 20 >> >> Nate >> >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> >> wrote: >> >>> -- >>> [ Picked text/plain from multipart/alternative ] >>> Interesting, thanks for finding that. >>> >>> I wonder if eastl is actually faster, more portable, etc. I'm sure it >>> satisfies their desire for a simpler std::allocator. But, I would have >>> >> liked >> >>> to see some performance comparisons in this paper. There's nothing like >>> >> hard >> >>> numbers to justify the time they spent rewriting/redesigning the STL. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>> I found a good site that details EA's own version of STL and why game >>>> >>> > companies don't use STL. >>> > >>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html >>> > >>> > Paul Peloski wrote: >>> > > -- >>> > > [ Picked text/plain from multipart/alternative ] >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I >>> >> really >> >>> > like >>> > > the STL (and Boost). Is there some important consideration I missed >>> > about >>> > > their usage with the Source SDK? >>> > > >>> > > Regards, >>> > > >>> > > Paul >>> > > >>> > >>> > _______________________________________________ >>> > To unsubscribe, edit your list preferences, or view the list >>> >> archives, >> >>> > please visit: >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> > >>> > >>> -- >>> >>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> >> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
