Taken from Lummox's comment in the Pixel Movement feature request:
In a nutshell, an Appearance is everything about the physical appearance of an atom or a component of one. It has information about the icon, state, text, name, direction (this can be overridden by other things), layer, overlays and underlays, verbs, mouse pointers, opacity and luminosity and other visual doodads, and pixel offsets. Whenever you add an item to atom.overlays, two things happen: 1) An Appearance snapshot is taken of what you're adding, and that's what gets added to or subtracted from the overlays. 2) Adding to the overlays creates a new Appearance for the main object, since it has a different list of overlays. (If you loop through an overlays list and use the \ref macro you'll see that they use a different internal type than atoms; however the : operator can access most of their vars on at least a read-only basis.) As another example, if you change mob.icon, a new Appearance is generated if necessary and assigned to the mob.
Appearances are sent to the client on an as-needed basis, if the client doesn't have them already. Any client that knows about the appearance counts toward its refcount, and it won't be recycled until nobody is left who knows or cares about it. Clients also periodically tell the server about appearances they don't need to hold onto anymore.
The speed problem I'm referring to here is that Appearances also contain pixel offsets. This is a good thing because it lets overlays have pixel offsets, but if you change the pixel offset of a mob it would probably be more sensible to just send an update of the offsets and send a "neutral" appearance with no offsets or at least just the defaults. If the server didn't have to create a new Appearance for these cases, it would be able to skip a few steps like trying to find if an Appearance with the correct offsets already existed and if not creating it. In a game with lots of pixel movement, this can obviously happen frequently, more so than say a change of direction. The speed benefits might be subtle but with lower tick_lag I think they may come into play more and more. This also could translate into bandwidth savings as the offsets could represent just a six-byte bump per atom instead of sending a whole Appearance to the client, with the only downside being that in theory Appearances wouldn't need to be sent after a while but the offsets still would.