There is no point in using arrays because of memory moving penalty. A linked list will keep about the same amount of memory as a tree, the sole difference would be that finding would be log(n) instead of n. Removing and adding to a linked list is maximum O(n), and to a queue is O(1)
And the memory usage you presume it's still less than 5 % of what you say uhub uses.
Netfraction Inception
-
Pietry
- Senior Member
- Posts: 328
- Joined: Tue Dec 04, 2007 7:25 am
- Location: Bucharest
Re: Netfraction Inception
Just someone
-
Dj_Offset
- Member
- Posts: 53
- Joined: Mon Sep 15, 2008 9:48 pm
- Location: adcs://adcs.uhub.org:1511
Re: Netfraction Inception
The memory usage I am objecting to is not the memory required for a full hub, but the wasteful requirement to allocate memory for a hub that is close to empty, or just severely misconfigured.
For a hub with 50 users which is configured to theoretically handle 10000 users (hub owner could be an optimist
, that would waste ~1MB of memory for no good reason.
I guess it all just boils down to design issues, although I don't see any compelling reason for choosing this particular one compared to the other ones already outlined.
For a hub with 50 users which is configured to theoretically handle 10000 users (hub owner could be an optimist
I guess it all just boils down to design issues, although I don't see any compelling reason for choosing this particular one compared to the other ones already outlined.
-
Pietry
- Senior Member
- Posts: 328
- Joined: Tue Dec 04, 2007 7:25 am
- Location: Bucharest
Re: Netfraction Inception
While thinking about this issue, I thought about this: dynamically allocate queue numbers. Keep the queue about the size of the user count and add more to it if there are enough users to get them. One could design this without looking to max user count. ( That could be just a way to keep users from entering )
Just someone
-
darkKlor
- Senior Member
- Posts: 100
- Joined: Tue Dec 30, 2008 2:59 pm
Re: Netfraction Inception
I think the best reason for using a queue is that the dequeue operation is very cheap on the CPU, and you want the algorithm to be at it's fastest when a user connects and a new SID is needed. The queue operation after the user disconnects is more costly, but at that point who cares? The operation will likely occur in it's own thread, and the length of time to connect a user is vastly more important than the disconnect time.
There is no need to test for collisions with the queue method, only that the queue contains available elements i.e. Queue.Count > 0. Also, the performance of the queue should not vary over the lifetime of the hub. The key disadvantage is all the extra memory allocated which may never be used.
There is no need to test for collisions with the queue method, only that the queue contains available elements i.e. Queue.Count > 0. Also, the performance of the queue should not vary over the lifetime of the hub. The key disadvantage is all the extra memory allocated which may never be used.
-
Pietry
- Senior Member
- Posts: 328
- Joined: Tue Dec 04, 2007 7:25 am
- Location: Bucharest
Re: Netfraction Inception
Which IMHO is very little.The key disadvantage is all the extra memory allocated which may never be used.
Just someone
Who is online
Users browsing this forum: Google (Crawler) and 0 guests