Why does the "group by class" interface of the dominator tree need to return objectIds?

[mycxu]

When I request this interface, it returns the objectId of all class objects, but I haven't found where these objectIds are used. Additionally, when the number of objects is very large, this interface becomes extremely time-consuming. Are these IDs used somewhere?
{"namespace":"heap-dump","api":"dominatorTree.roots","target":"d6e46031-e176-4190-bb51-dd2042a43d67","parameters":{"groupBy":"BY_CLASS","searchText":"","searchType":"by_name","sortBy":"retainedHeap","ascendingOrder":false,"page":1,"pageSize":50}}

[D-D-H]

It seems that 'objectIds' is not required for Dominator Tree API.

I remember there are APIs that need it, like Histogram.

when the number of objects is very large, this interface becomes extremely time-consuming.

Yes, it is indeed a problem. We didn't find an elegant way to solve it.

Maybe we can consider maintaining a map (generating and returning a key when objectIds is needed for subsequent requests). But there will be a new problem: when to clean the map.

[mycxu]

Yes, the timing for map cleanup does not seem easy to estimate. I directly modified the Dominator Tree interface so that it no longer returns objectIds. The program's functionality can still operate normally with this change, and it appears that it will not impact other interfaces.