ID:1395581
 Oct 10 2013, 11:33 am
|
|||||||||||||
| |||||||||||||
When using icon.Height() to find the height of an icon that is part of a rather large icon file, the profiler is reporting a high length of processing time. In my case, I am using an icon file generated by DMI Fonts Plus and it is taking about .01 seconds per call. Oddly, it seems that calling icon.Height() again on the same file uses significantly less CPU, though it's still enough to register in the profiler.
| |||||||||||||
|
Oct 10 2013, 3:28 pm
|
|
Lummox JR
   |
I'm not sure this is so much a bug as a place where performance could stand to be improved. It's not as if it's returning bogus results.
|
True, it doesn't return bogus results, but the call time is significantly longer than that of icon.Width(). This strikes me as wrong when considering that DMIs seem to PNGs whose width is (states+frames)*icon_width and whose height is simply icon_height. Considering this, I figured that icon.Width() would be the longer call.
It also seemed odd that Height() almost doubled DrawBox()'s call time even though DrawBox() had five times the amount of calls. | |
Width() or Height() should be identical in their run times, but whichever is called first may be taking longer. I think that's what you're seeing.
Internally, the same routine handles both. When dealing with an open /icon datum, the routine may have to calculate the existing client-side operations in order to be sure of the width and height: it takes some shortcuts so it doesn't have to do all the ops on the server side, just calculate how size is impacted. There is some caching involved, which is why your subsequent calls are faster. Overall I think this is best moved to Feature Requests, as the current behavior is correct, but might be possible to improve via some performance tweaks. So I'll go ahead and move that now. | |