Opened 9 years ago

Closed 8 years ago

#635 closed performance (wontfix)

healthbars eats perf when not drawing any bars

Reported by: Bluestone Owned by: Bluestone
Priority: minor Milestone:
Component: BA trunk Version:
Keywords: Cc:


only applies when below its cutoff height (above a certain height it does nothing at all) - but /give all and zoom reasonably close & it eats perf but draws nothing

this is not related to [2454] (which has only small perf impact) although it does affect BAR too

Change History (9)

comment:1 by Floris, 9 years ago

I see nothing wrong or odd

the code responisble for the perf impact is:

line: 960

if (sec1>1/25) and ((cy-smoothheight)^2 < maxUnitDistance) then
    sec1 = 0
    visibleUnits = GetVisibleUnits(-1,nil,false)
Last edited 9 years ago by Floris (previous) (diff)

comment:2 by Bluestone, 9 years ago

Didn't read the code (yet) but calling Spring.GetVisibleUnits 25 times per sec (which i guess is what that code snippet does) is wrong and odd! Table creation/deletion in lua is an expensive operation, unfortunately.

comment:3 by Bluestone, 9 years ago

After some testing, the time taken for the GetVisibleUnits call is not the major cause of this.

Last edited 9 years ago by Bluestone (previous) (diff)

comment:4 by Bluestone, 9 years ago

Type: defectperformance

comment:5 by Floris, 9 years ago

Old healthbars issue... I guess because it checks every unit for health, so drawing nothing doesnt even matter. Also dont forget with give all nukes and other units draw 'loading' bars aswell.

comment:6 by Bluestone, 9 years ago

No - the checks for unit stats cost very little, even done at this magnitude. The cause is table deletion/regeneration.

comment:7 by Floris, 8 years ago

turned config var 'featureReclaimVisibility' to false, so it wont loop all features at normal height, just on closeup.

this doesnt fix your description though

Last edited 8 years ago by Floris (previous) (diff)

comment:8 by Bluestone, 8 years ago

This issue is assigned to me (note that it's BA trunk, at least for now) and I haven't yet evaluated whether or not it's worth fixing.

Please concentrate on fixing the issues in your own code, which without really look, I would guess are due to making too many gl calls.

comment:9 by Bluestone, 8 years ago

Resolution: wontfix
Status: newclosed

probably not worth the trouble

Note: See TracTickets for help on using tickets.