Small correction... A 'naked' object holding a boolean takes 12 bytes, adding an int makes it 16 bytes, and adding up to 3 booleans will not change this, as the CLR will change the lay-out and put all booleans in one Int32, however adding 4 booleans will make it 20 bytes long.
Willy. ----- Original Message ----- From: "Willy Denoyette" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, April 29, 2002 8:08 PM Subject: Re: [DOTNET] lock - how expensive is it to call? > As far I can see a 'naked' Object instance takes 12 Bytes, one with a single int 16 >and adding 1 up to 4 boolean takes > 20 bytes. > > Willy. > > ----- Original Message ----- > From: "Henk de Koning" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, April 29, 2002 7:12 PM > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > Ahhh. The current build aligns on a 4 byte boundary. So, what you're saying > > is, adding one boolean could actually increase in-memory class size with 4 > > bytes ? Wow ... > > > > -- Henkk ;-) > > > > BTW, a naked System.Object instance seems to take 32 bytes. A user defined > > class with one Int32, takes 36 bytes. Adding 1 bool to that will take 40 > > bytes. > > > > ----- Original Message ----- > > From: "Valery Pryamikov" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, April 29, 2002 2:50 PM > > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > > > Not necessarily ;-). > > > Memory allocators usually align memory block to the integer boundary > > > (and even to 64 bites boundary), so adding one byte could be not > > > essential for the memory consumption (depending on the object layout and > > > size). > > > > > > -Valery. > > > > > > -----Original Message----- > > > From: Henk de Koning [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, April 29, 2002 2:47 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > > Whereas your solution would increase object size for each and every > > > instance > > > ... > > > > > > Now I'm pushing it, I now ;-);-) > > > > > > -- Henkk > > > > > > ----- Original Message ----- > > > From: "Valery Pryamikov" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Monday, April 29, 2002 2:34 PM > > > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > > > > > > You right here:-). > > > > > > > > -----Original Message----- > > > > From: Henk de Koning [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, April 29, 2002 2:37 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > > > > Would be expensive for exactly one call (out of 300.000). > > > > > > > > -- Henkk ;-) > > > > > > > > ----- Original Message ----- > > > > From: "Valery Pryamikov" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Monday, April 29, 2002 2:29 PM > > > > Subject: Re: [DOTNET] lock - how expensive is it to call? > > > > > > > > > > > > > Your latest code should work, of course, but using second lock would > > > > be > > > > > quite an expensive addition... And you only need a memory write > > > > barrier > > > > > between <init stuff> and bNeedInit = false. Using two different > > > > > fNeedInit+fNeedInitInt fields is more efficient solution for lazy > > > init > > > > > problem (you already have mem.barrier during lock release). > > > > > > > > > > Cheers, > > > > > -Valery. > > > > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > > > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
