Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a VF Controller class with several instance of a wrapper class - something like this:

public Transient mywrapperclass wrapper1 {get;set;}
public Transient mywrapperclass wrapper2 {get;set;}
public Transient mywrapperclass wrapper3 {get;set;}

I was looking to make it cleaner, and wondered if I would be better off with one Map that I reference on the page e.g.

Map<String, mywrapperclass> mywrapperclasses {get;set;}

I could then add each instance of the wrapper to the map, and reference it on the the VF page with the usual VF Map syntax e.g.


But reading this answer makes me pause - so I was trying to work out if it would improve performance, harm performance or make no difference before I make the changes...

share|improve this question
Thanks - the null pointer issue is a good one - I hit that a lot with VF and maps and it does ruin my day. It works well enough, and if there are aren't compelling performance gains, I'll leave as is... – BritishBoyinDC Mar 27 '14 at 2:46
up vote 3 down vote accepted

In all likelihood, your performance will be "about the same" (in the case of just three or four elements). However, given that maps are still fragile as far as Visualforce is concerned, you should probably avoid them if your only purpose is to make your code "look nice." In fact, if that were truly a concern, you would do better with a "wrapper" class, so that you'd have:


This is more efficient than a map, and doesn't suffer from the null-pointer risk; if a map refers to a non-existent key, you'll run into an error message that can't be caught and will really ruin your day. I found that out the hard way during a project, and ended up using wrappers anyways.

share|improve this answer

First off, if you aren't including an apex:form tag in your page viewstate will not exist, and there will be no hit there (viewstate is by the way exceedingly slow since there's a number of system operations added to every interaction with the page because of it).

Seeing as your sample variables are all declared transient I'd assume your map would be as well, and in that case there would be viewstate impact from it.

Internally apex maps are backed by java HashMaps, which are reasonably fast until you get very large number of entries, or many entries that have similar hash codes (which apex manages for you nicely in most cases).

It really comes down to your requirements in the end, if you have an unpredictable or otherwise variable number of wrapper objects the map has some major advantages here, but if you're only going to have a handful of them, and you're hardcoding the map keys in the page it sounds like it would be cleaner and faster overall to have them as separate variables.

At the end of the day I'd strongly suspect that you'd be hard pressed to notice a performance difference between the two (unless you're counting single digits of miliseconds) for most applications. As always apex can be unpredictable and depending on how the standard implementation of hashCode handles your wrapper type it may vary. Always benchmark it on relevant types and data if it's going to be a major concern.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.