ArC: Cost of Instance.select()

[famod]

Hi @mkouba & @manovotn (and possibly @Ladicek)!

Is Instance.select(NamedLiteral.of(...)).get() any "costly"? Should I better build a Map in the constructor of my bean (or in @PostConstruct)?

Thanks!

[quarkus-bot[bot]]

/cc @manovotn, @mkouba

[famod]

Ah, my old friend! Nice to see you here as well. 😁 (I need vacation)

[manovotn]

Hi @famod,

what beans are you resolving?

For normal scoped beans this isn't anyhow costly - it's a matter of few object allocations, resolution process (based on type and qualifier) and returning you a proxy. Although I should note that there is little reason to use Instance if you could just @Inject and store the beans you need in fields. While the resolution process isn't costly, it is still doing something which cannot compete with things like plain field access. Especially if you're going to do that repeatedly.

If it is @Dependent beans you are talking about, then this will make a huge difference as Instance will by default always create new contextual reference (i.e. new actual bean) each time you invoke Instance.get().

[famod]

It's a few @ApplicationScoped beans. The Instance is narrowed down to the base type of those beans.

I should note that there is little reason to use Instance if you could just @Inject and store the beans you need in fields.

Well, at this point the bean in question shall not know all implementations. It shall select the right one based on a parameter that each of its public methods has.
That's why Instance felt like the natural, "generic" way of achieving that.

Also, we are lazy an let lombok create all of our constructors. Since I don't like having an Instance field and and Map (that basically contains the same beans), I would need to do the Map building in the constructor.
Still, a Map seems like the most efficient way then...

[manovotn]

Since I don't like having an Instance field and and Map (that basically contains the same beans)

Note that Instance doesn't "contain" any beans (except for dependent instances created from it).

That's why Instance felt like the natural, "generic" way of achieving that.

Yes, Instance is indeed a good match for such scenario.

Still, a Map seems like the most efficient way then...

That really depends. Instance is doing some bean pre-fetching as well (see impl code).
I don't think you'd gain much if anything by using map on top of it...

EDIT: I should note that the prefetching is not for beans as in contextual instances, merely for their metadata.

[famod]

Since I don't like having an Instance field and and Map (that basically contains the same beans)

Note that Instance doesn't "contain" any beans (except for dependent instances created from it).

Right, "represents" would have been more appropriate.

Still, a Map seems like the most efficient way then...

That really depends. Instance is doing some bean pre-fetching as well (see impl code). I don't think you'd gain much if anything by using map on top of it...

Ok thanks! Let's see what my colleagues have to say about this during PR review.