On 2011-10-03 16:17, Moriz Gupte wrote:
> Am wondering if anyone from Linden Lab can comment on this thread.
> This is such an important issue regarding mesh viewers and mesh based
> economy. Many mesh builders are reverting products back to sculpty
> versions because the majority of clients ref
On 10/02/2011 12:45 PM, Henri Beauchamp wrote:
> On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote:
>
>> One more note. I have 16gb of memory on this system so the large heap
>> really isnt a problem per-se.
> It is, because you will not be able to get more than 3Gb of virtual
> memory per proc
> That define is really only used for some statics code in
> llallocator.cpp. It does
> not influence if tcmalloc is used or not.
its not clear where/why/when it is used - any code path includuing tcmalloc
on linux 32bit isn't compiled, though the viewer crashes if it isn't linked,
which in my o
> in GooglePerfTools.cmake:
> set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1)
> and in llcommon property pages
> Undefine Preprocessor Definitions: LL_USE_TCMALLOC=1
> So it would appear, at least by default, that tcmalloc is not enabled. Am
> I understanding this wrong? Or does LL build their viewer wit
PM
Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues
Am wondering if anyone from Linden Lab can comment on this thread. This is such
an important issue regarding mesh viewers and mesh based economy. Many mesh
builders are reverting products back to sculpty versions because the
sted
>
> > Date: Sat, 1 Oct 2011 22:24:56 +0200
> > From: sl...@free.fr
> > To: opensource-dev@lists.secondlife.com
> > Subject: [opensource-dev] Mesh viewers and tcmalloc issues
>
> >
> > Greetings,
> >
> > I noticed that all the viewers using tcmal
nvToDouble("TCMALLOC_RELEASE_RATE", 1.0) (in 3p-google-perftools) and it
seems to do exactly the same as without it. Twisted > Date: Sat, 1 Oct 2011
22:24:56 +0200
> From: sl...@free.fr
> To: opensource-dev@lists.secondlife.com
> Subject: [opensource-dev] Mesh viewers an
On 10/02/2011 12:45 PM, Henri Beauchamp wrote:
> On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote:
>
>> One more note. I have 16gb of memory on this system so the large heap
>> really isnt a problem per-se.
> It is, because you will not be able to get more than 3Gb of virtual
> memory per proc
On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote:
> One more note. I have 16gb of memory on this system so the large heap
> really isnt a problem per-se.
It is, because you will not be able to get more than 3Gb of virtual
memory per process, and when this virtual space gets fragmented (whic
On Sun, 02 Oct 2011 10:12:57 -0400, Mike Chase wrote:
> On 10/02/2011 03:48 AM, Henri Beauchamp wrote:
> > On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
> >
> >> Setting this as described for me made the client (on Linux) so slow as
> >> to be unuseable. I am seeing occasional crashesas w
On Sun, 2 Oct 2011 16:39:49 +0200, Carlo Wood wrote:
> On Sun, 2 Oct 2011 10:20:47 +0200
> Henri Beauchamp wrote:
>
> > Really, the only true motivation behind the use of tcmalloc in mesh
> > viewers (it was not use for non-mesh viewers) is to provide aligned
> > allocations. Without it, and the
On Sun, 2 Oct 2011 10:20:47 +0200
Henri Beauchamp wrote:
> Really, the only true motivation behind the use of tcmalloc in mesh
> viewers (it was not use for non-mesh viewers) is to provide aligned
> allocations. Without it, and the way the mesh viewer code is written,
> the viewer simply crashes
On 10/02/2011 10:12 AM, Mike Chase wrote:
> On 10/02/2011 03:48 AM, Henri Beauchamp wrote:
>> On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
>>
>>> Setting this as described for me made the client (on Linux) so slow as
>>> to be unuseable. I am seeing occasional crashesas well and tried thi
On 10/02/2011 03:48 AM, Henri Beauchamp wrote:
> On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
>
>> Setting this as described for me made the client (on Linux) so slow as
>> to be unuseable. I am seeing occasional crashesas well and tried this
>> as a workaround.
> I can tell you the slow
_
From: Lance Corrimal
To: opensource-dev@lists.secondlife.com
Sent: Sunday, October 2, 2011 7:12 AM
Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues
Am Sonntag, 2. Oktober 2011 schrieb WolfPup Lowenhar:
> Lance,
> Nicky P has a new fix for
> https://jira.secondlife.com/
Am Sonntag, 2. Oktober 2011 schrieb WolfPup Lowenhar:
> Lance,
> Nicky P has a new fix for
> https://jira.secondlife.com/browse/OPEN-69 this will allow Open
> Source Developers using the Express version of Visual Studios
> properly build all 3p-libs as well as the viewer.
awesome!
i guess I'll use
fe.com [mailto:opensource-dev-
> boun...@lists.secondlife.com] On Behalf Of Lance Corrimal
> Sent: Sunday, October 02, 2011 2:39 AM
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues
>
> Am Samstag, 1. Oktober 2011 schrieb Henri Beau
Am Sonntag, 2. Oktober 2011 schrieb Henri Beauchamp:
> > 1. is simple enough but what do i do about 2?
>
> Simply recover the v1.7 version of 3p-google-perftools: it compiles
> fine here (under VS2005).
Doesn't under VS2010 EXPRESS...
what now?
bye,
LC
___
On Sun, 2 Oct 2011 08:39:06 +0200, Lance Corrimal wrote:
> second, two issues:
>
> 1. viever_manifest.py needs to be edited to reflect the fact that
> libtcmalloc.so now has the version 0.2.2 and not 0.1.0 :)
Yes, unless you recompile v1.7.
> 2. 3p-google-perftools does not build under VS2010
On Sun, 2 Oct 2011 01:12:40 -0400, Zabb65 wrote:
> It is not desirable to let the default allocation engine run under
> Linux, and possibly Mac. glibc has an incredibly slow allocator for
> small objects, and tcmalloc was implemented to remedy these
> situations(This is what I heard, but have not
Am Sonntag, 2. Oktober 2011 schrieb Henri Beauchamp:
> On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
> > Setting this as described for me made the client (on Linux) so
> > slow as to be unuseable. I am seeing occasional crashesas well
> > and tried this as a workaround.
>
> I can tell you
On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
> Setting this as described for me made the client (on Linux) so slow as
> to be unuseable. I am seeing occasional crashesas well and tried this
> as a workaround.
I can tell you the slow down is *certainly* not coming from this fix:
I cond
Am Samstag, 1. Oktober 2011 schrieb Henri Beauchamp:
first, if this works as advertized... henri, you rock. majorly. I've
seen a scorpions live concert on their last world tour rock more but
not much.
second, two issues:
1. viever_manifest.py needs to be edited to reflect the fact that
libtc
It is not desirable to let the default allocation engine run under
Linux, and possibly Mac. glibc has an incredibly slow allocator for
small objects, and tcmalloc was implemented to remedy these
situations(This is what I heard, but have not confirmed.) Inventory
and a few other items create massive
On 10/01/2011 04:24 PM, Henri Beauchamp wrote:
> Greetings,
>
> I noticed that all the viewers using tcmalloc (mesh viewers under Linux
> and Windows, since those use SSE2 and must gain memory-aligned malloc()
> and new() calls that their standard library does not provide) suffer
> from a serious p
Thank you Henri.
On Sat, Oct 1, 2011 at 2:24 PM, Henri Beauchamp wrote:
> Greetings,
>
> I noticed that all the viewers using tcmalloc (mesh viewers under Linux
> and Windows, since those use SSE2 and must gain memory-aligned malloc()
> and new() calls that their standard library does not provide
Greetings,
I noticed that all the viewers using tcmalloc (mesh viewers under Linux
and Windows, since those use SSE2 and must gain memory-aligned malloc()
and new() calls that their standard library does not provide) suffer
from a serious problem: they never release memory back to the system,
mean
27 matches
Mail list logo
