unlimited queue size

[Eugen Graf]

Hello all,

if I see an unlimited queue size, I think LV must realloc the memory every operation with this queue. Now I ask me, its only if the size is unlimited or the memory will be reallocate if the size is definied?

If the memory will be reallocate, its more more slower as the "normally" queue in other programming languages.

Eugen

[LAVA 1.0 Content]

CITATION(Eugen Graf @ Mar 29 2007, 09:27 PM)

Hello all,

if I see an unlimited queue size, I think LV must realloc the memory every operation with this queue. Now I ask me, its only if the size is unlimited or the memory will be reallocate if the size is definied?

If the memory will be reallocate, its more more slower as the "normally" queue in other programming languages.

Eugen

Good question... If I was at work I would test it on different computers to see if the Q size is actually unlimited !

I am interested in the answer and the reasons...

[LAVA 1.0 Content]

As I understand it, queues will dynamically allocate memory, but free memory only when destroyed. The online help states:

Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Enqueue the maximum number of elements and flush the queue to preallocate the queue. The queue reserves more memory as its size increases and releases that memory only when you destroy the queue.

I almost always create my queues as part of my application startup using a fixed size, immediately populate them with dummy data (to reserve the memory) and then flush the queue.

I think allowing a queue grow to unbounded is "asking for trouble".

[Eugen Graf]

QUOTE(LV Punk @ Mar 30 2007, 01:50 PM)

As I understand it, queues will dynamically allocate memory, but free memory only when destroyed. The online help states:

Note

max queue size

only limits the number of elements in the queue. It does not preallocate memory. Enqueue the maximum number of elements and flush the queue to preallocate the queue. The queue reserves more memory as its size increases and releases that memory only when you destroy the queue.

Thank you very much for this information.

QUOTE(LV Punk @ Mar 30 2007, 01:50 PM)

I almost always create my queues as part of my application startup using a fixed size, immediately populate them with dummy data (to reserve the memory) and then flush the queue.

Do you do it in a for loop? So in your initialisation step? Can you post an exapmple? Thanks

QUOTE(LV Punk @ Mar 30 2007, 01:50 PM)

I think allowing a queue grow to unbounded is "asking for trouble".

Its right.

Eugen

[LAVA 1.0 Content]

QUOTE(Eugen Graf @ Mar 30 2007, 08:15 AM)

Can you post an exapmple? Thanks

http://forums.lavag.org/index.php?act=attach&type=post&id=5370

http://forums.lavag.org/index.php?act=attach&type=post&id=5371 (LV 8.0)

[Eugen Graf]

Very helpfull, thanks a lot.

Eugen

[Aristos Queue]

QUOTE(LV Punk @ Mar 30 2007, 06:50 AM)

I think allowing a queue grow to unbounded is "asking for trouble".

It could be a problem, but it's absolutely amazing how often it works just fine. CPUs are fast enough compared with various bus speeds that the dequeue loops for most apps I've seen -- particularly for data aquisition stuff -- are way faster than the enqueue loops, so the queues stay small.

[Eugen Graf]

QUOTE(LV Punk @ Mar 30 2007, 07:55 PM)

http://forums.lavag.org/index.php?act=attach&type=post&id=5370

http://forums.lavag.org/index.php?act=attach&type=post&id=5371 (LV 8.0)

Thanks, but it's only for "string" queues. If I have a queue of other datatype I have to adapt your BD to my type. Are there any possibility to adapt the data type(e.g. by variant), I can use this VI for every queue?

Eugen

[LAVA 1.0 Content]

QUOTE(Eugen Graf @ Apr 25 2007, 02:41 AM)

Are there any possibility to adapt the data type(e.g. by variant), I can use this VI for every queue?

Yes, you can replace the string constant with a variant control (see attached). Wire the desired queue type to the input, and LabVIEW will coerce to this. Note that the queue will now be of type variant. That means that when you dequeue you will need to know the data type of the queue in order to use the Variant to Data function.

http://forums.lavag.org/index.php?act=attach&type=post&id=5629

http://forums.lavag.org/index.php?act=attach&type=post&id=5630

[Eugen Graf]

Thank you, I will assuradly use it.

Eugen

[jpdrolet]

QUOTE(LV Punk @ Mar 30 2007, 01:55 PM)

http://forums.lavag.org/index.php?act=attach&type=post&id=5370

http://forums.lavag.org/index.php?act=attach&type=post&id=5371 (LV 8.0)

It is far from being evident that LabVIEW keeps the strings data in the queue. While it can keep as many as string handles as the queue size, I doubt it keeps the data itself in the queue but just place holders for handles. I would think it is the same for variable length data like arrays and variants. On dequeuing, does LabVIEW copy the string to the caller (keeping an copy internal to the queue) or just pass the string handle?

[i2dx]

QUOTE(jpdrolet @ Apr 25 2007, 03:14 PM)

It is far from being evident that LabVIEW keeps the strings data in the queue. While it can keep as many as string handles as the queue size, I doubt it keeps the data itself in the queue but just place holders for handles. I would think it is the same for variable length data like arrays and variants. On dequeuing, does LabVIEW copy the string to the caller (keeping an copy internal to the queue) or just pass the string handle?

Allthough I don not know it, I'd bet that enqueuing / dequeuing is a *call by reference* operation. I can't see any sense for duplicating the data, just for the purpose to hand them over to an other function without any modification. And I can not imagine how to implement polymorphic behaviour on a primitive without pointer operations ...