* [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys
2025-09-05 11:51 [pve-devel] [PATCH manager 0/4] gui/api performance improvements Dominik Csapak
@ 2025-09-05 11:51 ` Dominik Csapak
2025-09-05 13:49 ` Aaron Lauterer
2025-09-05 13:57 ` Daniel Kral
2025-09-05 11:52 ` [pve-devel] [PATCH manager 2/4] ui: fix O(n^2) calculations when loading /cluster/resources Dominik Csapak
` (3 subsequent siblings)
4 siblings, 2 replies; 10+ messages in thread
From: Dominik Csapak @ 2025-09-05 11:51 UTC (permalink / raw)
To: pve-devel
the idea was that we get any of the 'new' versions on lookup, but that
lead to iterating through possibly all keys. Since that was called for
each resource in e.g. /cluster/resources api call, the runtime was
O(n^2) for the number of resources.
To avoid that, simply look up the currently only valid key here which
makes this lookup much cheaper.
In my test setup with ~10000 guests, it reduces the time for a call
to /cluster/resources from ~22s to ~400ms
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
NOTE: this is only a workaround and Aaron is working to making this
whole part unnecessary, but for now i think this is a good stop-gap
PVE/API2Tools.pm | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
index abe73fa2..863f5f55 100644
--- a/PVE/API2Tools.pm
+++ b/PVE/API2Tools.pm
@@ -52,10 +52,9 @@ sub get_rrd_key {
return "pve2.3-${type}/${id}";
}
- # if no old key has been found, we expect on in the newer format: pve-{type}-{version}/{id}
- # We accept all new versions, as the expectation is that they are only allowed to add new colums as non-breaking change
- for my $k (keys %$rrd) {
- return $k if $k =~ m/^pve-\Q${type}\E-\d\d?.\d\/\Q${id}\E$/;
+ my $key = "pve-${type}-9.0/${id}";
+ if (defined($rrd->{$key})) {
+ return $key;
}
}
--
2.47.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys
2025-09-05 11:51 ` [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys Dominik Csapak
@ 2025-09-05 13:49 ` Aaron Lauterer
2025-09-05 13:53 ` Dominik Csapak
2025-09-05 13:57 ` Daniel Kral
1 sibling, 1 reply; 10+ messages in thread
From: Aaron Lauterer @ 2025-09-05 13:49 UTC (permalink / raw)
To: Proxmox VE development discussion, Dominik Csapak
On 2025-09-05 14:06, Dominik Csapak wrote:
> the idea was that we get any of the 'new' versions on lookup, but that
> lead to iterating through possibly all keys. Since that was called for
> each resource in e.g. /cluster/resources api call, the runtime was
> O(n^2) for the number of resources.
>
> To avoid that, simply look up the currently only valid key here which
> makes this lookup much cheaper.
>
> In my test setup with ~10000 guests, it reduces the time for a call
> to /cluster/resources from ~22s to ~400ms
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> NOTE: this is only a workaround and Aaron is working to making this
> whole part unnecessary, but for now i think this is a good stop-gap
>
> PVE/API2Tools.pm | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
> index abe73fa2..863f5f55 100644
> --- a/PVE/API2Tools.pm
> +++ b/PVE/API2Tools.pm
> @@ -52,10 +52,9 @@ sub get_rrd_key {
> return "pve2.3-${type}/${id}";
> }
>
> - # if no old key has been found, we expect on in the newer format: pve-{type}-{version}/{id}
> - # We accept all new versions, as the expectation is that they are only allowed to add new colums as non-breaking change
> - for my $k (keys %$rrd) {
> - return $k if $k =~ m/^pve-\Q${type}\E-\d\d?.\d\/\Q${id}\E$/;
> + my $key = "pve-${type}-9.0/${id}";
> + if (defined($rrd->{$key})) {
> + return $key;
Have you tested this in a mixed PVE8 + PVE9 cluster? This might break it
and we might have to keep the dynamic checking around.
I don't have too much time right now. But I think this would break a
mixed version situation, e.g. during a cluster upgrade, where we receive
both keys, pve2-... and pve-...-9.0 ones.
> }
> }
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys
2025-09-05 13:49 ` Aaron Lauterer
@ 2025-09-05 13:53 ` Dominik Csapak
2025-09-05 13:58 ` Aaron Lauterer
0 siblings, 1 reply; 10+ messages in thread
From: Dominik Csapak @ 2025-09-05 13:53 UTC (permalink / raw)
To: Aaron Lauterer, Proxmox VE development discussion
On 9/5/25 3:49 PM, Aaron Lauterer wrote:
>
>
> On 2025-09-05 14:06, Dominik Csapak wrote:
>> the idea was that we get any of the 'new' versions on lookup, but that
>> lead to iterating through possibly all keys. Since that was called for
>> each resource in e.g. /cluster/resources api call, the runtime was
>> O(n^2) for the number of resources.
>>
>> To avoid that, simply look up the currently only valid key here which
>> makes this lookup much cheaper.
>>
>> In my test setup with ~10000 guests, it reduces the time for a call
>> to /cluster/resources from ~22s to ~400ms
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>> NOTE: this is only a workaround and Aaron is working to making this
>> whole part unnecessary, but for now i think this is a good stop-gap
>>
>> PVE/API2Tools.pm | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
>> index abe73fa2..863f5f55 100644
>> --- a/PVE/API2Tools.pm
>> +++ b/PVE/API2Tools.pm
>> @@ -52,10 +52,9 @@ sub get_rrd_key {
>> return "pve2.3-${type}/${id}";
>> }
>> - # if no old key has been found, we expect on in the newer format:
>> pve-{type}-{version}/{id}
>> - # We accept all new versions, as the expectation is that they are
>> only allowed to add new colums as non-breaking change
>> - for my $k (keys %$rrd) {
>> - return $k if $k =~ m/^pve-\Q${type}\E-\d\d?.\d\/\Q${id}\E$/;
>> + my $key = "pve-${type}-9.0/${id}";
>> + if (defined($rrd->{$key})) {
>> + return $key;
>
> Have you tested this in a mixed PVE8 + PVE9 cluster? This might break it
> and we might have to keep the dynamic checking around.
>
> I don't have too much time right now. But I think this would break a
> mixed version situation, e.g. during a cluster upgrade, where we receive
> both keys, pve2-... and pve-...-9.0 ones.
>
>> }
>> }
>
but isn't that why the checks above (outside the context) are there?:
---
# check for old formats: pve2-{type}/{id}. For VMs and CTs the version
number is different than for nodes and storages
if ($type ne "vm" && exists $rrd->{"pve2-${type}/${id}"}) {
return "pve2-${type}/${id}";
} elsif ($type eq "vm" && exists $rrd->{"pve2.3-${type}/${id}"}) {
return "pve2.3-${type}/${id}";
}
---
?
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys
2025-09-05 13:53 ` Dominik Csapak
@ 2025-09-05 13:58 ` Aaron Lauterer
0 siblings, 0 replies; 10+ messages in thread
From: Aaron Lauterer @ 2025-09-05 13:58 UTC (permalink / raw)
To: Dominik Csapak, Proxmox VE development discussion
On 2025-09-05 15:52, Dominik Csapak wrote:
>
>
> On 9/5/25 3:49 PM, Aaron Lauterer wrote:
>>
>>
>> On 2025-09-05 14:06, Dominik Csapak wrote:
>>> the idea was that we get any of the 'new' versions on lookup, but that
>>> lead to iterating through possibly all keys. Since that was called for
>>> each resource in e.g. /cluster/resources api call, the runtime was
>>> O(n^2) for the number of resources.
>>>
>>> To avoid that, simply look up the currently only valid key here which
>>> makes this lookup much cheaper.
>>>
>>> In my test setup with ~10000 guests, it reduces the time for a call
>>> to /cluster/resources from ~22s to ~400ms
>>>
>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>> ---
>>> NOTE: this is only a workaround and Aaron is working to making this
>>> whole part unnecessary, but for now i think this is a good stop-gap
>>>
>>> PVE/API2Tools.pm | 7 +++----
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
>>> index abe73fa2..863f5f55 100644
>>> --- a/PVE/API2Tools.pm
>>> +++ b/PVE/API2Tools.pm
>>> @@ -52,10 +52,9 @@ sub get_rrd_key {
>>> return "pve2.3-${type}/${id}";
>>> }
>>> - # if no old key has been found, we expect on in the newer
>>> format: pve-{type}-{version}/{id}
>>> - # We accept all new versions, as the expectation is that they
>>> are only allowed to add new colums as non-breaking change
>>> - for my $k (keys %$rrd) {
>>> - return $k if $k =~ m/^pve-\Q${type}\E-\d\d?.\d\/\Q${id}\E$/;
>>> + my $key = "pve-${type}-9.0/${id}";
>>> + if (defined($rrd->{$key})) {
>>> + return $key;
>>
>> Have you tested this in a mixed PVE8 + PVE9 cluster? This might break
>> it and we might have to keep the dynamic checking around.
>>
>> I don't have too much time right now. But I think this would break a
>> mixed version situation, e.g. during a cluster upgrade, where we
>> receive both keys, pve2-... and pve-...-9.0 ones.
>>
>>> }
>>> }
>>
>
> but isn't that why the checks above (outside the context) are there?:
you are right! sorry for the noise
>
> ---
> # check for old formats: pve2-{type}/{id}. For VMs and CTs the version
> number is different than for nodes and storages
> if ($type ne "vm" && exists $rrd->{"pve2-${type}/${id}"}) {
> return "pve2-${type}/${id}";
> } elsif ($type eq "vm" && exists $rrd->{"pve2.3-${type}/${id}"}) {
> return "pve2.3-${type}/${id}";
> }
> ---
>
> ?
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys
2025-09-05 11:51 ` [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys Dominik Csapak
2025-09-05 13:49 ` Aaron Lauterer
@ 2025-09-05 13:57 ` Daniel Kral
1 sibling, 0 replies; 10+ messages in thread
From: Daniel Kral @ 2025-09-05 13:57 UTC (permalink / raw)
To: Proxmox VE development discussion; +Cc: pve-devel
On Fri Sep 5, 2025 at 1:51 PM CEST, Dominik Csapak wrote:
> the idea was that we get any of the 'new' versions on lookup, but that
> lead to iterating through possibly all keys. Since that was called for
> each resource in e.g. /cluster/resources api call, the runtime was
> O(n^2) for the number of resources.
>
> To avoid that, simply look up the currently only valid key here which
> makes this lookup much cheaper.
>
> In my test setup with ~10000 guests, it reduces the time for a call
> to /cluster/resources from ~22s to ~400ms
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> NOTE: this is only a workaround and Aaron is working to making this
> whole part unnecessary, but for now i think this is a good stop-gap
>
> PVE/API2Tools.pm | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm
> index abe73fa2..863f5f55 100644
> --- a/PVE/API2Tools.pm
> +++ b/PVE/API2Tools.pm
> @@ -52,10 +52,9 @@ sub get_rrd_key {
> return "pve2.3-${type}/${id}";
> }
>
> - # if no old key has been found, we expect on in the newer format: pve-{type}-{version}/{id}
> - # We accept all new versions, as the expectation is that they are only allowed to add new colums as non-breaking change
> - for my $k (keys %$rrd) {
> - return $k if $k =~ m/^pve-\Q${type}\E-\d\d?.\d\/\Q${id}\E$/;
> + my $key = "pve-${type}-9.0/${id}";
> + if (defined($rrd->{$key})) {
> + return $key;
> }
> }
>
Quickly tested this, because I experienced that in a 1500 guests 3-node
cluster too and at least this patch reduced the time for
/cluster/resources from 657.7±39.3 ms to 65.7±6.2 ms with 10 samples,
nice!
Didn't have a mixed-version cluster available currently, so I couldn't
test what @Aaron pointed out in another thread.
Else, consider this:
Tested-by: Daniel Kral <d.kral@proxmox.com>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* [pve-devel] [PATCH manager 2/4] ui: fix O(n^2) calculations when loading /cluster/resources
2025-09-05 11:51 [pve-devel] [PATCH manager 0/4] gui/api performance improvements Dominik Csapak
2025-09-05 11:51 ` [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys Dominik Csapak
@ 2025-09-05 11:52 ` Dominik Csapak
2025-09-05 11:52 ` [pve-devel] [PATCH manager 3/4] ui: resource tree: improve performance on initial update Dominik Csapak
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Dominik Csapak @ 2025-09-05 11:52 UTC (permalink / raw)
To: pve-devel
when we fetch the cluster resources, the ui calculates some fields for
each resource, such as 'hostmem_usage'. This requires the maxmem
attribute from the host which we have to look up in the resource store.
Since the data is not sorted in the store itself, extjs linearly goes
through the records to make the lookup when we use 'findExact'.
So instead of using findExact for every guest (which iterates the whole
resource store again), use a 'nodeCache' there and clear it out before
we load the new data.
This reduces the total time used for 'cacluate_hostmem_usage'
in my test setup (~10000 non-running vms) from 4,408.2 ms to 12.4 ms.
(Measured with the `Performance` tab in Chromium)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
www/manager6/Utils.js | 12 ++++--------
www/manager6/data/ResourceStore.js | 20 ++++++++++++++++++++
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/www/manager6/Utils.js b/www/manager6/Utils.js
index 57a818f6..c48ee0b2 100644
--- a/www/manager6/Utils.js
+++ b/www/manager6/Utils.js
@@ -1070,8 +1070,7 @@ Ext.define('PVE.Utils', {
return -1;
}
- var index = PVE.data.ResourceStore.findExact('id', 'node/' + data.node);
- var node = PVE.data.ResourceStore.getAt(index);
+ let node = PVE.data.ResourceStore.getNodeById(data.node);
if (!Ext.isDefined(node) || node === null) {
return -1;
}
@@ -1093,8 +1092,7 @@ Ext.define('PVE.Utils', {
return '';
}
- var index = PVE.data.ResourceStore.findExact('id', 'node/' + record.data.node);
- var node = PVE.data.ResourceStore.getAt(index);
+ let node = PVE.data.ResourceStore.getNodeById(record.data.node);
if (!Ext.isDefined(node) || node === null) {
return '';
}
@@ -1148,8 +1146,7 @@ Ext.define('PVE.Utils', {
return -1;
}
- var index = PVE.data.ResourceStore.findExact('id', 'node/' + data.node);
- var node = PVE.data.ResourceStore.getAt(index);
+ let node = PVE.data.ResourceStore.getNodeById(data.node);
if (!Ext.isDefined(node) || node === null) {
return -1;
@@ -1199,8 +1196,7 @@ Ext.define('PVE.Utils', {
return '';
}
- var index = PVE.data.ResourceStore.findExact('id', 'node/' + record.data.node);
- var node = PVE.data.ResourceStore.getAt(index);
+ let node = PVE.data.ResourceStore.getNodeById(record.data.node);
var maxmem = node.data.maxmem || 0;
if (record.data.mem > 1) {
diff --git a/www/manager6/data/ResourceStore.js b/www/manager6/data/ResourceStore.js
index d1f3fb63..bf740129 100644
--- a/www/manager6/data/ResourceStore.js
+++ b/www/manager6/data/ResourceStore.js
@@ -2,6 +2,8 @@ Ext.define('PVE.data.ResourceStore', {
extend: 'Proxmox.data.UpdateStore',
singleton: true,
+ nodeCache: {},
+
findVMID: function (vmid) {
let me = this;
return me.findExact('vmid', parseInt(vmid, 10)) >= 0;
@@ -21,6 +23,22 @@ Ext.define('PVE.data.ResourceStore', {
return nodes;
},
+ getNodeById: function (id) {
+ let me = this;
+
+ if (!me.nodeCache[id]) {
+ let idx = me.findExact('id', `node/${id}`);
+ me.nodeCache[id] = me.getAt(idx);
+ }
+
+ return me.nodeCache[id];
+ },
+
+ clearCache: function () {
+ let me = this;
+ me.nodeCache = {};
+ },
+
storageIsShared: function (storage_path) {
let me = this;
@@ -372,5 +390,7 @@ Ext.define('PVE.data.ResourceStore', {
});
me.callParent([config]);
+
+ me.on('beforeload', me.clearCache, me);
},
});
--
2.47.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* [pve-devel] [PATCH manager 3/4] ui: resource tree: improve performance on initial update
2025-09-05 11:51 [pve-devel] [PATCH manager 0/4] gui/api performance improvements Dominik Csapak
2025-09-05 11:51 ` [pve-devel] [PATCH manager 1/4] API2Tools: rrd: remove O(n^2) lookup for keys Dominik Csapak
2025-09-05 11:52 ` [pve-devel] [PATCH manager 2/4] ui: fix O(n^2) calculations when loading /cluster/resources Dominik Csapak
@ 2025-09-05 11:52 ` Dominik Csapak
2025-09-05 11:52 ` [pve-devel] [PATCH manager 4/4] ui: resource tree: fix change detection Dominik Csapak
2025-09-05 17:40 ` [pve-devel] applied: [PATCH manager 0/4] gui/api performance improvements Thomas Lamprecht
4 siblings, 0 replies; 10+ messages in thread
From: Dominik Csapak @ 2025-09-05 11:52 UTC (permalink / raw)
To: pve-devel
When we insert nodes into the tree, we use 'insertBefore' of extjs'
NodeInterface. When the node is inside a TreeStore, it calls
'registerNode' to handle some events and accounting. Sadly it does so
not only for the inserted node, but also for the node in which is
inserted too and that calls 'registerNode' again for all of its
children.
So inserting a large number of guests under node this way has (at least)
O(n^2) calls to registerNode.
To workaround this, create the first tree node structure outside the
TreeStore and add it at the end. Further insertions are more likely to
only come in small numbers. (Still have to look into if we can avoid
that behavior there too)
This improves the time spend in 'registerNode' (in my ~10000 guests test
setup) from 4,081.6 ms to about 2.7ms.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
www/manager6/tree/ResourceTree.js | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/www/manager6/tree/ResourceTree.js b/www/manager6/tree/ResourceTree.js
index 30754455..f9f711b6 100644
--- a/www/manager6/tree/ResourceTree.js
+++ b/www/manager6/tree/ResourceTree.js
@@ -328,10 +328,22 @@ Ext.define('PVE.tree.ResourceTree', {
return node;
};
+ let firstUpdate = true;
+
let updateTree = function () {
store.suspendEvents();
- let rootnode = me.store.getRootNode();
+ let rootnode;
+ if (firstUpdate) {
+ rootnode = Ext.create('Ext.data.TreeModel', {
+ expanded: true,
+ id: 'root',
+ text: gettext('Datacenter'),
+ iconCls: 'fa fa-server',
+ });
+ } else {
+ rootnode = me.store.getRootNode();
+ }
// remember selected node (and all parents)
let sm = me.getSelectionModel();
let lastsel = sm.getSelection()[0];
@@ -451,6 +463,11 @@ Ext.define('PVE.tree.ResourceTree', {
me.selectById(lastsel.data.id);
}
+ if (firstUpdate) {
+ me.store.setRoot(rootnode);
+ firstUpdate = false;
+ }
+
// on first tree load set the selection from the stateful provider
if (!pdata.updateCount) {
rootnode.expand();
--
2.47.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* [pve-devel] [PATCH manager 4/4] ui: resource tree: fix change detection
2025-09-05 11:51 [pve-devel] [PATCH manager 0/4] gui/api performance improvements Dominik Csapak
` (2 preceding siblings ...)
2025-09-05 11:52 ` [pve-devel] [PATCH manager 3/4] ui: resource tree: improve performance on initial update Dominik Csapak
@ 2025-09-05 11:52 ` Dominik Csapak
2025-09-05 17:40 ` [pve-devel] applied: [PATCH manager 0/4] gui/api performance improvements Thomas Lamprecht
4 siblings, 0 replies; 10+ messages in thread
From: Dominik Csapak @ 2025-09-05 11:52 UTC (permalink / raw)
To: pve-devel
when trying to detect changes of resources, we compare a list of
properties of the existing nodes in the tree with the ones we got from
the api call, so that we can update only those that changed.
One of these properties is the 'text' one, which is calculated from e.g.
the vmid and name (or the name and host, depending on the type).
Sadly, when inserting/updating the node, we modified the text property
in every case, at least adding a '<span></span>' around the existing
text. This meant that every resource was updated every time instead of
only when something changed.
To fix this, remote the 'text' property from the to checked ones, and
add all the properties that are used to compile the text one.
This reduces the time of updateTree in my test-setup (~10000 guests)
when nothing changed from ~100ms to ~15ms and reduces scroll stutter
during such an update.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
www/manager6/tree/ResourceTree.js | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/www/manager6/tree/ResourceTree.js b/www/manager6/tree/ResourceTree.js
index f9f711b6..7a8d00c0 100644
--- a/www/manager6/tree/ResourceTree.js
+++ b/www/manager6/tree/ResourceTree.js
@@ -291,7 +291,11 @@ Ext.define('PVE.tree.ResourceTree', {
let stateid = 'rid';
const changedFields = [
- 'text',
+ 'disk',
+ 'maxdisk',
+ 'vmid',
+ 'name',
+ 'type',
'running',
'template',
'status',
--
2.47.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* [pve-devel] applied: [PATCH manager 0/4] gui/api performance improvements
2025-09-05 11:51 [pve-devel] [PATCH manager 0/4] gui/api performance improvements Dominik Csapak
` (3 preceding siblings ...)
2025-09-05 11:52 ` [pve-devel] [PATCH manager 4/4] ui: resource tree: fix change detection Dominik Csapak
@ 2025-09-05 17:40 ` Thomas Lamprecht
4 siblings, 0 replies; 10+ messages in thread
From: Thomas Lamprecht @ 2025-09-05 17:40 UTC (permalink / raw)
To: pve-devel, Dominik Csapak
On Fri, 05 Sep 2025 13:51:58 +0200, Dominik Csapak wrote:
> this series fixes a series of bad patterns in our api/gui code,
> especially some O(n^2) code regarding resource count (vms/storages/etc.)
>
> note that the api change is only a current stop-gap workaround and aaron
> is working on making that code not necessary at all, but for now this
> should be good.
>
> [...]
Applied all patches to master and also cherry picked them for stable-8, thanks!
[1/4] API2Tools: rrd: remove O(n^2) lookup for keys
commit: 695d3b1cb2a4c53044c3016ea2748205c6b20f5d
[2/4] ui: fix O(n^2) calculations when loading /cluster/resources
commit: 525738c070254c1a48681c9c6398dc9b25bb3ec5
[3/4] ui: resource tree: improve performance on initial update
commit: d2660fc7a4b5add154e5694dc40a188d9403ab47
[4/4] ui: resource tree: fix change detection
commit: e19de81f5469eb2e4e45296ebeef16754abacc7a
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 10+ messages in thread