[GH-ISSUE #254] Performance Enhancing #116

New issue

Closed

opened 2026-02-27 15:48:54 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 15:48:54 +03:00

Owner

Originally created by @yankejustin on GitHub (Jun 1, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/254

Context

With the desirability of many possible connected clients or tasks that may otherwise be intensive or expensive even for a few clients, some changes are necessary to fix the large memory usage and much of the CPU usage of the server.

Reasons

At first glance, it is visible that the Client object is expensive: the client has a variable named Value that stores 8 Forms each, with other items that can be large, such as UnsafeStreamCodec after some use.

Plan

I suggest changing some of how a Client is perceived by the server. Implementation of client management is something that will need to be abstracted from the Server object and should be placed in a ClientPool object that will handle much of the interaction between the other Client objects. While interaction between Client and the GUI of the server will remain somewhat the same, the big changes introduced by this suggestion is similar to the following:

Performance increase from the lack of need to keep track of Clients in ways such as indexing the ListView of them.
Accurate handling of clients.
- Clients are all in one consolidated object.
- No need to manually keep track of the Client by inefficiently indexing a List using indices that can be incorrect.
No more individual Forms for each Client object.
- This is the biggest memory hog being slain. Without all these Forms in each Client object, things suddenly become much more simple.
- Clients should hold the state of these forms. By such, I mean that the clients should be holding values instead an individual Form. The selected Client can simply give its values out to the opening Form. Multiple Forms function the same way, but (of course) each form will receive each selected client's values.

Request for Action

I have been mashing away on my keyboard a bit tonight, but I do not want to put this right into MaxXor/master and I don't want to only keep this code on my branch either. I would appreciate it if you would create a new MaxXor/Performance branch for some collaboration on this task. This task will require that some Forms are loaded a bit differently (to pull data from the client instead of setting or changing the Form itself into the client).

Originally created by @yankejustin on GitHub (Jun 1, 2015). Original GitHub issue: https://github.com/quasar/Quasar/issues/254 <h1>Context</h1> With the desirability of many possible connected clients or tasks that may otherwise be intensive or expensive even for a few clients, some changes are necessary to fix the large memory usage and much of the CPU usage of the server. <h1>Reasons</h1> At first glance, it is visible that the <b>Client</b> object is expensive: the client has a variable named <code>Value</code> that stores <b>8</b> Forms each, with other items that can be large, such as <code>UnsafeStreamCodec</code> after some use. <h1>Plan</h1> I suggest changing some of how a Client is perceived by the server. Implementation of client management is something that will <i>need</i> to be abstracted from the <code>Server</code> object and should be placed in a <code>ClientPool</code> object that will handle much of the interaction between the other <code>Client</code> objects. While interaction between Client and the GUI of the server will remain somewhat the same, the <i>big</i> changes introduced by this suggestion is similar to the following: 1. Performance increase from the lack of need to keep track of Clients in ways such as indexing the <code>ListView</code> of them. 2. Accurate handling of clients. - Clients are all in one consolidated object. - No need to manually keep track of the Client by inefficiently indexing a <code>List</code> using indices that can be incorrect. 3. <b>No more individual Forms for each <code>Client</code> object.</b> - This is the biggest memory hog being slain. Without all these Forms in each <code>Client</code> object, things suddenly become much more simple. - Clients should hold the <i>state</i> of these forms. By such, I mean that the clients should be holding <i>values</i> instead an individual Form. The selected Client can simply give its values out to the opening Form. Multiple Forms function the same way, but (of course) each form will receive each selected client's values. <h1>Request for Action</h1> I have been mashing away on my keyboard a bit tonight, but I do not want to put this right into <code>MaxXor/master</code> and I don't want to only keep this code on my branch either. I would appreciate it if you would create a new <code>MaxXor/Performance</code> branch for some collaboration on this task. This task will require that some Forms are loaded a bit differently (to pull data from the client instead of setting or changing the Form itself into the client).

kerem

2026-02-27 15:48:54 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 15:48:54 +03:00

Author

Owner

@yankejustin commented on GitHub (Jun 7, 2015):

The biggest performance kicker is management of the buffers. For this reason, I this issue will be closed.

@yankejustin commented on GitHub (Jun 7, 2015): The biggest performance kicker is management of the buffers. For this reason, I this issue will be closed.

kerem referenced this issue

2026-02-27 15:52:42 +03:00

[PR #116] [MERGED] Added Socks5 Reverse Proxy #984