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 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, 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
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
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
___
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.
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com [mailto:
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
I was trying to get all libraries to build w/o modifying the library source.
google-perftools is/was on the needs work list. Vcexpress doesn't have a
command line switch /Upgrade as devenv does. However, you can open an older
solution file in the VS2010 Express IDE and it will upgrade to the lat
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
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 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 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, 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, 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 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
15 matches
Mail list logo
