synclock performance

[Keith Langer]

I would like to know why locking on a new object takes significantly
longer than locking on a strongly typed object. All of the posts I've
seen say that it is best to lock on a "new object", but it takes more
than 3x longer than locking on anything other than object. Here's a
test case:

Module Module1

Sub Main()

Dim T As clsTest
Dim i As Integer
Dim D As Date
Const MAX = 10000000
Dim LL As New Object
Dim DTest As Date
Dim T2 As New clsDummy


T = New clsTest
D = Now
For i = 1 To MAX
T.Index += 1
Next
Console.WriteLi ne("No lock: " & Now.Ticks - D.Ticks)

T = New clsTest
D = Now
For i = 1 To MAX
SyncLock T
T.Index += 1
End SyncLock
Next
Console.WriteLi ne("Lock on owner: " & Now.Ticks - D.Ticks)

T = New clsTest
D = Now
For i = 1 To MAX
SyncLock LL
T.Index += 1
End SyncLock
Next
Console.WriteLi ne("Lock on new object: " & Now.Ticks - D.Ticks)


T = New clsTest
D = Now
For i = 1 To MAX
SyncLock T2
T.Index += 1
End SyncLock
Next
Console.WriteLi ne("Lock on Dummy object: " & Now.Ticks -
D.Ticks)

Console.ReadLin e()


End Sub

Class clsDummy

End Class

Class clsTest
Dim m_Index As Integer
Public Property Index() As Integer
Get
Return m_Index
End Get
Set(ByVal Value As Integer)
m_Index += 1
End Set
End Property
End Class



thanks,
Keith


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Mattias Sjögren]

Re: synclock performance

Keith,
[color=blue]
>I would like to know why locking on a new object takes significantly
>longer than locking on a strongly typed object.[/color]

Because on each iteration there's a call to

Microsoft.Visua lBasic.Compiler Services.FlowCo ntrol.CheckForS yncLockOnValueT ype()

which throws an exception if you're trying to lock on a boxed value
type, because that isn't allowed in VB.

[color=blue]
>All of the posts I've
>seen say that it is best to lock on a "new object", but it takes more
>than 3x longer than locking on anything other than object.[/color]

I bet all those posts used it in more realistic situations though. For
a one time lock, the perf difference hardly matters. I hope you don't
have real code that looks like what you posted.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Keith Langer]

Re: synclock performance

Mattias,

Obviously this was just a test case to demonstrate the differences,
and not real code. In light of the performance difference, doesn't it
make more sense to use an empty custom class instead of a generic
object?

Keith


Mattias Sjögren <mattias.dont.w ant.spam@mvps.o rg> wrote in message news:<#$IKSMY2D HA.2336@TK2MSFT NGP09.phx.gbl>. ..[color=blue]
> Keith,
>[color=green]
> >I would like to know why locking on a new object takes significantly
> >longer than locking on a strongly typed object.[/color]
>
> Because on each iteration there's a call to
>
> Microsoft.Visua lBasic.Compiler Services.FlowCo ntrol.CheckForS yncLockOnValueT ype()
>
> which throws an exception if you're trying to lock on a boxed value
> type, because that isn't allowed in VB.
>
>[color=green]
> >All of the posts I've
> >seen say that it is best to lock on a "new object", but it takes more
> >than 3x longer than locking on anything other than object.[/color]
>
> I bet all those posts used it in more realistic situations though. For
> a one time lock, the perf difference hardly matters. I hope you don't
> have real code that looks like what you posted.
>
>
>
> Mattias[/color]

[Mattias Sjögren]

Re: synclock performance

Keith,
[color=blue]
>In light of the performance difference, doesn't it
>make more sense to use an empty custom class instead of a generic
>object?[/color]

Personally I wouldn't bother. At least not unless the code was in a
tight loop or something and profiling the code showed that it was a
bottleneck and needed some extra perf boost.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.