Queue._size = 0

  • Thread starter Thread starter news.microsoft.com
  • Start date Start date
N

news.microsoft.com

Hi,

I notice in the debugger that the _size member of a Queue is 0 even tho
its been initialised, is it always 0 on construction and not the default
size? So on the first .Enqueue(object) it will then grow. Weird, why is the
_array memeber set to 32 (also the same value as _ShrinkThreshold).

So why is _size = 0 and what is _size for then if it isnt the size of the
Queue._array ?

Thanks.
 
news.microsoft.com said:
I notice in the debugger that the _size member of a Queue is 0 even tho
its been initialised, is it always 0 on construction and not the default
size? So on the first .Enqueue(object) it will then grow. Weird, why is the
_array memeber set to 32 (also the same value as _ShrinkThreshold).

So why is _size = 0 and what is _size for then if it isnt the size of the
Queue._array ?
Click to expand...

Just guessing, but think of Queue._array as a buffer, which has
Queue._size "real" items in it. That means you can add items to it
without resizing the array every time - but you've got to know how much
of it is taken up with real data and how much is just spare capacity.
 
Ok but the synchronized wrapper says _size = 0 when there is _size = 2 in
the real underlaying queue (unsynchronised queue).

Is this correct? Shouldnt the syncronized wrapper also say _size = 2?
 
Ok so .Count is the property accessor for _size field in the underlaying
(unscynrhronised - never could spell that word dammit) implementation?


news.microsoft.com said:
Ok but the synchronized wrapper says _size = 0 when there is _size = 2 in
the real underlaying queue (unsynchronised queue).

Is this correct? Shouldnt the syncronized wrapper also say _size = 2?



is
the
Click to expand...
of
Click to expand...
 
news.microsoft.com said:
Ok but the synchronized wrapper says _size = 0 when there is _size = 2 in
the real underlaying queue (unsynchronised queue).
Is this correct? Shouldnt the syncronized wrapper also say _size = 2?
Click to expand...

I don't know about the synchronized wrapper, to be honest.

Why are you interested in the implementation, by the way? Is it not
behaving as you expect it to in terms of the public API?
 
news.microsoft.com said:
Ok so .Count is the property accessor for _size field in the underlaying
(unscynrhronised - never could spell that word dammit) implementation?
Click to expand...

I really don't know - but you shouldn't usually worry about exactly how
the implementation works, to be honest. Stick with the public API.
 
news.microsoft.com said:
Because its showing in the debugger watch list. If its shown, its relevant
Click to expand...

No, that's not true. The debugger isn't going to know which bits of
implementation you're supposed to be interested in - (i.e. your classes
as opposed to Microsoft's) and very occasionally it *is* relevant if
you're trying to find out why the implementation isn't behaving as you
believe it should, as described by the public API. For the vast
majority of the time, however, there's no reason to be interested in
the implementation.
 
Well, I want to monitor a queue resizing (if any) in perfmon using
performance counters to fine tune my dequeuing.
I have .Count property for the amount of items in the queue, but I want to
check the growing and shrinking (if any as I would prefer not to have this
as its an O(n) - array copy operation).
 
1. I agree with Jon, you are now looking into implementation and you should
only be coding to what they guaurentee through the public API.

2. Sometimes the documentation isn't good enough so you want/need to know
what is going on underneath. My advice here is look at Queue through the
ILDASM and see whats going on. You could even go through the shared source
code of .NET and probably see what the Queue is doing and see if the same
behavior is there. Warning though, in the next release of .NET, the Queue
class may not be, and is not guaranteed to be the same and all your internal
assumptions could be thrown out the window.

3. Post some code that duplicates the behavior. I could not duplicate it.
The sync'd queue and the non-synced queue were always the same.

- J
 
Well it would help to be able to monitor the grow sizes for fine tuning my
dequeing and queue size.

currently .Count property isnt enough, thats just the current amount of
queued items and not the size of the actual queue.
 
Well why don't you look the ILDASM, I took a look at it and the
implementation isn't that big and its all right there. You would know the
whole algorithm, and matter of fact you could probably round trip it and
build a debug version you could then step thru.
 
news.microsoft.com said:
Well it would help to be able to monitor the grow sizes for fine tuning my
dequeing and queue size.

currently .Count property isnt enough, thats just the current amount of
queued items and not the size of the actual queue.
Click to expand...

The Queue class does not keep track of the size of the data structure
that underlies the Queue (it's simply an array) - it just queries the
array length when it needs to know that information.

If you need to get to that information at runtime, I suspect the best
way to do it is to use reflection to get at the private _array member of
the Queue class, and ask the array for its Length.

I'd insert the standard disclaimer about how this info can change, etc.,
but that's been covered extensively already in this thread.
 
Sure the info may change, but still we can reperf it again on the new
version of the runtime.

I just dont want my queue to be resizing when I could avoid it by dequing
better or a better initial size.
 
I know its a array and I saw a _size member which I guess I could get by
reflection, but I dono why they dont allow us to publically see the size so
we can fine tune our queueing on the caller.



news.microsoft.com said:
Sure the info may change, but still we can reperf it again on the new
version of the runtime.

I just dont want my queue to be resizing when I could avoid it by dequing
better or a better initial size.

tuning
Click to expand...
 
Did you read what I said! To repeat "matter of fact you could probably round
trip it and
build a debug version you could then step thru." Thats runtime!
WTF will ILDASM do, thats static
Click to expand...
Uuh, you read the IL source of queue, learn the algorithm, and know how to
tweak your usage to the actual implemented algorithm. This gives you more
power than looking at some private variables.
 
All I need is a number to display in perfmon , why should I spend time
disassembling a class when I can get the private value via reflection at
runtime on ANY build?

Did you read what I was trying to do, why do I need the algoritm, I dont
give a rats ass about the algorithm, I dont care if it adds 2 bananas onto
the end of the queue, I just want the SIZE of the queue to see if its
increasing (O(n) for the array copy on growing), then I can set my dequeuing
better.

Did you read what I said, patronising tit.
 
Back
Top