There are multiple problems with ContextMenu with regards to performance:

1) RT-36100 - ChoiceBox that is never opened needs to know it's ContextMenu full with, but that currently means we need to have fully populated ContextMenu in the memory\

2)(from David Grieve)

I've spent the last few days in ContextMenuContent hell. One thing I noticed was that ContextMenuContent removes and replaces MenuItemContainers every time a menu is opened because of updateVisualItems. This causes a lot of overhead due to css pass and re-layout, not to mention a bunch of allocations. I'm surprised there aren't any leaks here.

I was thinking that ContextMenuContent should use VirtualFlow for MenuBox and MenuItemContainer would extend IndexedCell to add an updateItem(MenuItem) API. Then rather than removing and replacing the containers, updateVisualItems would just "updateItem".

When dealing with a sub-menu, you get a ContextMenu and every time you open a new sub-menu, that ContextMenu is reused firing change listeners all over the place because of adding/removing menu items. When you show a sub-menu, you get an updateVisualItems because the ContextMenu's items changed, then another right after because the ContextMenuContent popup is being shown and another because the old poup is no longer being shown (not necessarily in that order and some may be no-ops depending on itemsDirty).

Do we really need MenuBox? Why can't that layout code just be part of ContextMenuContent? Just make ContextMenuContent a VirtualFlow?