#Method is performance heavy

64 messages · Page 1 of 1 (latest)

nocturne atlas
#

this method is for some reason really performance heave and is taking a lot of time to process, the ImageIcon constructor seems to be causing it. anyone knows why

image.png
primal boughBOT
#

⌛ This post has been reserved for your question.

Hey @nocturne atlas! Please use /close or the Close Post button above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

timber abyss
silk dust
#

its the scaling of the image

nocturne atlas
#

its the constructor i think

image.png
#

of the ImageIcon

#

and here

image.png
dense wadi
#

how big are the images you are using?

silk dust
#

trust me its the scaling. Try using Image.SCALE_FAST instead of Image_SCALE_SMOOTH

dense wadi
#

And how long does it take to execute?

nocturne atlas
#

it managed to decrease from 1.5s to 387ms

image.png
dense wadi
#

Also how often are you calling the method?

nocturne atlas
#

it really seems like the issue of the construcotr

image.png
#

why would it be the getProperty method tho

timber abyss
nocturne atlas
silk dust
#

it shouldn't really take so long at this point in the program. image#getProperty should returns almost immediately

#

How long is the execution time for loadImage ?

nocturne atlas
#

it doesnt say that

#

is there something like a breakpoint for it?

silk dust
#

I haven't used the IntelliJ profiler myself so I can't tell you how you can measure a single method, sorry.

nocturne atlas
#

hm this method was written by someone else here i dont remember name, you sure this isnt causing the problem?

image.png
silk dust
#

I wrote that method, that's why I suggested you use Image.Scale_Fast instead of Image.SCALE_SMOOTH

nocturne atlas
#

i see

silk dust
#

The bottleneck is the image scaling

nocturne atlas
#

sorry i forgot your name lol

silk dust
#

no worries

dense wadi
#

what about caching the already scaled images?

nocturne atlas
#

like storing them if they were already loaded?

dense wadi
#

yes

nocturne atlas
dense wadi
nocturne atlas
# dense wadi yes

can i just compare them with .equals to check if its stored or theres better way?

dense wadi
#

and whenever you need the same image again, reuse it

dense wadi
silk dust
#

use a map, mapping the filename or the original BufferedImage to the scaled instance

dense wadi
#

you have random indices anyways

#

so you can use the already existing indices

#

and just store the scaled images there

nocturne atlas
dense wadi
nocturne atlas
#

youre correct now

#

nothing

#

since they're loaded at startup

#

ive implemented a simple caching and now its just this

image.png
#

but the second one is still taking some time as well

image.png
dense wadi
#

you could attempt to dirextly cache the ImageIcon objects instead

#

but is it really taking too long now?

silk dust
#

I am again pleading for a Map:
Map<BufferedImage,BufferedImage> imageMap which maps the original image (the one that is loaded via ImageIO.read to it's scaled instance (created via the method).
new images can simply be added to the map and retrieving of scaled instances is realtively cheap.

dense wadi
silk dust
#

the original non scaled image as the key, that retrieves the scaled instance

dense wadi
#

hashing and comparing images for looking up sounds like a waste of resources

#

just use the file name at that point

silk dust
#

you could also use the filename

dense wadi
#

if a plain array isn't an option

silk dust
#

but that could change.

silk dust
dense wadi
silk dust
#

yeah then a map is overkill

dense wadi
silk dust
#

I was assuming that another image could be loaded dynamically.

#

I just realised map doesn't even work for ImageIcon since it doesn't override the standard hashCode and equals methods