I need to implement CRUD operations on a data source which could be a physical table or logic (in-memory cache holds data after query multiple tables). Ideal choice for data source is table in db. But due to some reasons there is alternate implementation of having in-memory cache class mimic ideal implementation.
interface IEmp
{
Add();
Update();
Remove();
}
There are 2 implementation :
Class Emp
Operates on Physical table in sqlite
Class EmpCache
Operates in-memory cache - aggregate data from multiple other tables
Based on performance or other non functional needs consumer of class may chose to switch to either of 2 options.
I am thinking to apply design pattern here so that not causing much rework.
I see 2 design patterns applicable here:
a. Strategy pattern -
There will be 2 separate implementations of an interface IEmp (as above).
e.g.
Class EmpTable
{
IEmp table;
bool isInMemory;
}
based on isInMemory T/F table will switch underlying instance to 1 of above implementation {Emp or EmpCache}
b. Decorator pattern - another interface extends + encapsulate IEmp interface. And based on property change - it will act / delegate as appropriate
e.g.
IEmpCache : IEmp
{
IEmp instance;
bool useCache;
}
EmpCache : IEmpCache
{
Add()
{
if(!useCache)
{
instance.Add();
}
//cache logic
}
... // same for all other methods
}
I see approach b better, but mostly used when need to add/enhance already released functionality (class/interface), isn't it?
Which is better? Is there any other better pattern?
Definitely choice B is better.
If we first take a look at how the following patterns are classified. A decorator is a structural pattern and strategy is a behavioral pattern.
Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors.
Based on your question, you want to add new behavior to the existing object. Definition of the decorator is just like you describe your problem. Cache is the new behavior you want to add. I have used it in a similar problem and it usually works very well. It works well with a class that you can't change or with new features that could someday need caching.
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
I haven't used strategy to cache data. According to the definition, I think it has a different purpose. It can be harder to implement with already released classes. The strategy has many use cases and for example, it can be better when you do some calculations that may change.
I have used the strategy pattern when working with the database but it was a case where I wanted to support many different complex queries. In that way, I could just implement queries with strategy pattern and pass that strategy to object that handle database connection.
These past few days I've been thinking of a way to avoid needing to write a lot of code and still keeping a good performance for a Air desktop game I'm developing, as a hobby.
The game is a sort of vertical shooter, that consist of several entities moving and checking collision. There are plenty of different kind of units. Each frame I have something like:
entity.execute();
The simpler approach is to have all different entities to inherit the Entity class, and manually customize them all. This is slow and cumbersome, and hard to maintain. But it's fast, performance wise.
The other approach is to have only one Entity class, and just using some sort of composition to simply add "behaviors". So for example I have a master class with things like types of movements, attacks, etc, and the different entities use them.
The problem with that approach is, calling a function is slow, according to my tests, it is ~3 times slower than just having the code right there (inside execute()).
I'm in a dilemma, I can't find a way to reuse chunks of code to decorate generic Entity instances, and keep a good performance. Seems like I have to use one or the other.
I tried using [Inline], but I've read it's not a stable feature, and I didn't see any noticeable performance improvement, I didn't test it much though.
Any insight is appreciated.
Abstraction through inheritance is a good object oriented pattern, I'd argue that it is not slow or cumbersome to maintain. Separation of concerns would add clarity to classes that inherit your base Entity class; as well, reduce copied code. Interfaces would further abstract concrete types.
ActionScript does not support powerful object oriented language features that you might find in a language like C# - no abstract base class, no partial classes, limited template / generics, limited polymorphism. Composition and decorator patterns would likely force using dynamic classes, which would also slow down the runtime due to type checking.
Perhaps the greater issue is too much business logic in the Entity class. I would think some world container or controller would be responsible for collision detection.
Something you could consider is a physics engine like Box 2D.
There are ports of Box2D built with CrossBridge (formerly Alchemy, FlasCC), which is a C++ compiler for the AVM2, able to run Flash up to 10x faster through lean optimized bytecode that features high performance memory-access opcodes for Flash (known as Domain Memory).
This is how games like Angry Bots or Neverball are made.
Check out Jesse Sternberg's Box2d Flash Alchemy Port + World Construction Kit if using a AS3 physics engine sounds interesting.
There are some common approaches to speeding up the flash in game development. One of them is to avoid using display objects, in favour of simple bitmaps. In this case you have a stage as a bitmap, and keep all your game state in lightweight objects, and then just make a game state snapshot drawn into that stage bitmap data (with copyPixels) periodically (on enter frame, or on timer)
schematically: say you have a game with units
class PseudoSprite {
public var x:uint;
public var y:uint;
public var currentAnimFrame:uint;
protected var snapshotCreator:AbstractSnapshotCreator;
public function makeSnapshot():BitmapData {
return snapshotCreator.createSnapshot(currentAnimFrame);
}
....
}
class Unit extends PseudoSprite {
public var directionAngle:Number = 0;
public var speed:uint = 0;
function Unit() {
snapshotCreator = UnitSnapshotCreator.instance;
}
public function doStep():void {
x = //count x by speed and direction
y = //count y by speed and direction
animationFrame++;
}
}
class Game {
public var stage:Bitmap;
private var objects:Vector.<PseudoSprite> = new <PseudoSprite>[
new Unit(), new Unit()];
public function step() {
for each (var unit:PseudoSprite in objects) {
unit.doStep();
//draw unit.snapshot() to the stage bitmap data
}
}
}
so, you can see: you can build whole units (or all game objects) hierarchy using normal OOP, and get some suitable performance..
After some tests, I've found out that I can just do something like:
public var foo:Function;
and then when I create the entity I can:
entity.foo = myCustomFoo;
And then in the main loop I can:
entity.foo();
This is as performant as calling a native member function inside the Entity instance. Warning, don't create a getter to access your function, it becomes a lot slower.
In my game engine I use Box2D for physics. Box2D's naming conventions and poor commenting ruin the consistent and well documented remainder of my engine which is a little frustrating and presents poorly when you're using it.
I've considered making a set of wrapper classes for Box2D. That is, classes which extend each of the common Box2D objects and have their functions rewritten to follow the naming conventions of the rest of my engine, and to have them more clearly and consistently commented. I have even considered building ontop of some of the classes and adding some bits and pieces (like getters for pixel-based measurements in the b2Vec2 class).
This is fine but I am not 100% sure what the negative impacts of this would be and the degree to which those would affect my applications and games. I'm not sure if the compiler alleviates some of my concerns to a degree or whether I do need to be considerate when adding somewhat unnecessary classes for the sake of readability and consistency.
I have some suspicions:
More memory consumption to accommodate the extra level of class structure.
Performance impact when creating new objects due to initializing an extra level of members?
I am asking specifically about runtime impacts.
This is a pretty common problem when it comes to integrating third party libraries, especially libraries that are ports (as Box2DAS3 is), where they keep the coding and naming conventions of the parent language rather than fully integrating with the destination language (case in point: Box2DAS3 using getFoo() and setFoo() instead of a .foo getter/setter).
To answer your question quickly, no, there will be no significant performance impact with making wrapper classes; no more than you'll see in the class hierarchy in your own project. Sure, if you time a loop of 5 million iterations, you might see a millisecond or two of difference, but in normal usage, you won't notice it.
"More memory consumption to accommodate the extra level of class structure."
Like any language that has class inheritence, a vtable will be used behind the scenes, so you will have a small increase in memory/perf, but it's negligible.
"Performance impact when creating new objects due to initializing an extra level of members?"
No more than normal instantiation, so not something to worry about unless you're creating a huge amount of objects.
Performance wise, you should generally have no problem (favour readability and usability over performance unless you actually have a problem with it), but I'd look at it more as an architectural problem and, with that in mind, what I would consider to be a negative impact of extending/modifying classes of an external library generally fall into 3 areas, depending on what you want to do:
Modify the library
Extend the classes
Composition with your own classes
Modify the libary
As Box2DAS3 is open source, there's nothing stopping you jumping in and refactoring all the class/function names to your hearts content. I've seriously considered doing this at times.
Pros:
You can modify what you want - functions, classes, you name it
You can add any missing pieces that you need (e.g. pixel-meters conversion helpers)
You can fix any potential performance issues (I've noticed a few things that could be done better and faster if they were done in an "AS3" way)
Cons:
If you plan to keep your version up to date, you'll need to manually merge/convert any updates and changes. For popular libraries, or those that change a lot, this can be a huge pain
It's very time-consuiming - aside from modifications, you'll need a good understanding on what's going on so you can make any changes without breaking functionality
If there's multiple people working with it, they can't rely as much on external documentation/examples, as the internals might have changed
Extend the classes
Here, you simply make your own wrapper classes, which extend the base Box2D classes. You can add properties and functions as you want, including implementing your own naming scheme which translates to the base class (e.g. MyBox2DClass.foo() could simply be a wrapper for Box2DClass.bar())
Pros:
You implement just the classes you need, and make just the changes necessary
Your wrapper classes can still be used in the base Box2D engine - i.e. you can pass a MyBox2DClass object to an internal method that takes a Box2DClass and you know it'll work
It's the least amount of work, out of all three methods
Cons:
Again, if you plan to keep your version up to date, you'll need to check that any changes don't break your classes. Normally not much of a problem, though
Can introduce confusion into the class, if you create your own functions that call their Box2D equivalent (e.g. "Should I use setPos() or SetPosition()?). Even if you're working on your own, when you come back to your class in 6 months, you'll have forgotten
Your classes will lack coherence and consistency (e.g. some functions using your naming methodology (setPos()) while others use that of Box2D (SetPosition()))
You're stuck with Box2D; you can't change physics engines without a lot of dev, depending on how your classes are used throughout the project. This might not be such a big deal if you don't plan on switching
Composition with your own classes
You make your own classes, which internally hold a Box2D property (e.g. MyPhysicalClass will have a property b2Body). You're free to implement your own interface as you wish, and only what's necessary.
Pros:
Your classes are cleaner and fit in nicely with your engine. Only functions that you're interested in are exposed
You're not tied to the Box2D engine; if you want to switch to Nape, for example, you only need to modify your custom classes; the rest of your engine and games are oblivious. Other developers also don't need to learn the Box2D engine to be able to use it
While you're there, you can even implement multiple engines, and switch between them using a toggle or interfaces. Again, the rest of your engine and games are oblivious
Works nicely with component based engines - e.g. you can have a Box2DComponent that holds a b2Body property
Cons:
More work than just extending the classes, as you're essentially creating an intermediary layer between your engine and Box2D. Ideally, outside of your custom classes, there shouldn't be a reference to Box2D. The amount of work depends on what you need in your class
Extra level of indirection; normally it shouldn't be a problem, as Box2D will use your Box2D properties directly, but if your engine is calling your functions a lot, it's an extra step along the way, performance wise
Out of the three, I prefer to go with composition, as it gives the most flexibility and keeps the modular nature of your engine intact, i.e. you have your core engine classes, and you extend functionality with external libraries. The fact that you can switch out libraries with minimal effort is a huge plus as well. This is the technique that I've employed in my own engine, and I've also extended it to other types of libraries - e.g. Ads - I have my engine Ad class, that can integrate with Mochi, Kongregate, etc as needed - the rest of my game doesn't care what I'm using, which lets me keep my coding style and consistency throughout the engine, whilst still being flexible and modular.
----- Update 20/9/2013 -----
Big update time! So I went back to do some testing on size and speed. The class I used is too big to paste here, so you can download it at http://divillysausages.com/files/TestExtendClass.as
In it, I test a number of classes:
An Empty instance; a Class that just extends Object and implements an empty getPostion() function. This will be our benchmark
A b2Body instance
A Box2DExtends instance; a Class that extends b2Body and implements a function getPosition() that just returns GetPosition() (the b2Body function)
A Box2DExtendsOverrides instance; a Class that extends b2Body and overrides the GetPosition() function (it simply returns super.GetPosition())
A Box2DComposition instance; a Class that has a b2Body property and a getPosition() function that returns the b2Body's GetPosition()
A Box2DExtendsProperty instance; a Class that extends b2Body and adds a new Point property
A Box2DCompositionProperty instance; a Class that has both a b2Body property and a Point property
All tests were done in the standalone player, FP v11.7.700.224, Windows 7, on a not-great laptop.
Test1: Size
AS3 is a bit annoying in that if you call getSize(), it'll give you the size of the object itself, but any internal properties that are also Objects will just result in a 4 byte increase as they're only counting the pointer. I can see why they do this, it just makes it a bit awkward to get the right size.
Thus I turned to the flash.sampler package. If we sample the creation of our objects, and add up all the sizes in the NewObjectSample objects, we'll get the full size of our object (NOTE: if you want to see what's created and the size, comment in the log calls in the test file).
Empty's size is 56 // extends Object
b2Body's size is 568
Box2DExtends's size is 568 // extends b2Body
Box2DExtendsOverrides's size is 568 // extends b2Body
Box2DComposition's size is 588 // has b2Body property
Box2DExtendsProperty's size is 604 // extends b2Body and adds Point property
Box2DCompositionProperty's size is 624 // has b2Body and Point properties
These sizes are all in bytes. Some points worth noting:
The base Object size is 40 bytes, so just the class and nothing else is 16 bytes.
Adding methods doesn't increase the size of the object (they're implemented on a class basis anyway), while properties obviously do
Just extending the class didn't add anything to it
The extra 20 bytes for Box2DComposition come from 16 for the class and 4 for the pointer to the b2Body property
For Box2DExtendsProperty etc, you have 16 for the Point class itself, 4 for the pointer to the Point property, and 8 for each of the x and y property Numbers = 36 bytes difference between that and Box2DExtends
So obviously the difference in size depends on the properties that you add, but all in all, pretty negligible.
Test 2: Creation Speed
For this, I simply used getTimer(), with a loop of 10000, itself looped 10 (so 100k) times to get the average. System.gc() was called between each set to minimise time due to garbage collection.
Empty's time for creation is 3.9ms (av.)
b2Body's time for creation is 65.5ms (av.)
Box2DExtends's time for creation is 69.9ms (av.)
Box2DExtendsOverrides's time for creation is 68.8ms (av.)
Box2DComposition's time for creation is 72.6ms (av.)
Box2DExtendsProperty's time for creation is 76.5ms (av.)
Box2DCompositionProperty's time for creation is 77.2ms (av.)
There's not a whole pile to note here. The extending/composition classes take slightly longer, but it's like 0.000007ms (this is the creation time for 100,000 objects), so it's not really worth considering.
Test 3: Call Speed
For this, I used getTimer() again, with a loop of 1000000, itself looped 10 (so 10m) times to get the average. System.gc() was called between each set to minimise time due to garbage collection. All the objects had their getPosition()/GetPosition() functions called, to see the difference between overriding and redirecting.
Empty's time for getPosition() is 83.4ms (av.) // empty
b2Body's time for GetPosition() is 88.3ms (av.) // normal
Box2DExtends's time for getPosition() is 158.7ms (av.) // getPosition() calls GetPosition()
Box2DExtendsOverrides's time for GetPosition() is 161ms (av.) // override calls super.GetPosition()
Box2DComposition's time for getPosition() is 160.3ms (av.) // calls this.body.GetPosition()
Box2DExtendsProperty's time for GetPosition() is 89ms (av.) // implicit super (i.e. not overridden)
Box2DCompositionProperty's time for getPosition() is 155.2ms (av.) // calls this.body.GetPosition()
This one surprised me a bit, with the difference between the times being ~2x (though that's still 0.000007ms per call). The delay seems entirely down to the class inheritence - e.g. Box2DExtendsOverrides simply calls super.GetPosition(), yet is twice as slow as Box2DExtendsProperty, which inherits GetPosition() from its base class.
I guess it has to do with the overhead of function lookups and calling, though I took a look at the generated bytecode using swfdump in the FlexSDK, and they're identical, so either it's lying to me (or doesn't include it), or there's something I'm missing :) While the steps might be the same, the time between them probably isn't (e.g. in memory, it's jumping to your class vtable, then jumping to the base class vtable, etc)
The bytecode for var v:b2Vec2 = b2Body.GetPosition() is simply:
getlocal 4
callproperty :GetPosition (0)
coerce Box2D.Common.Math:b2Vec2
setlocal3
whilst var v:b2Vec2 = Box2DExtends.getPosition() (getPosition() returns GetPosition()) is:
getlocal 5
callproperty :getPosition (0)
coerce Box2D.Common.Math:b2Vec2
setlocal3
For the second example, it doesn't show the call to GetPosition(), so I'm not sure how they're resolving that. The test file is available for download if someone wants to take a crack at explaining it.
Some points to keep in mind:
GetPosition() doesn't really do anything; it's essentially a getter disguised as a function, which is one reason why the "extra class step penalty" appears so big
This was on a loop of 10m, which you're unlikely to doing in your game. The per-call penalty isn't really worth worrying about
Even if you do worry about the penalty, remember that this is the interface between your code and Box2D; the Box2D internals will be unaffected by this, only the calls to your interface
All-in-all, I'd expect the same results from extending one of my own classes, so I wouldn't really worry about it. Implement the architecture that works the best for your solution.
I know this answer will not qualify for the bounty as I am way to lazy to write benchmarks. But having worked on the Flash code base I can maybe give some hints:
The avm2 is a dynamic language, so the compiler will not optimize anything in this case.
Wrapping a call as a sub class call will have a cost. However that cost will be constant time and small.
Object creation cost will also at most be affected by a constant amount of time and memory. Also the time and amount will probably be insignificant compared to the base cost.
But, as with many things the devil is in the details. I never used box2d, but if it does any kind of object pooling things might not work well anymore. In general games should try to run without object allocations at play time. So be very careful not to add functions that allocate objects just to be prettier.
function addvectors(a:vec,b:vec,dest:vec):void
Might be ugly but is much faster than
function addvectors(a:vec,b:vec):vec
(I hope I got my AS3 syntax right...). Even more useful and more ugly might be
function addvectors(a:Vector.<vec>, b:Vector.<vec>, dest:Vector.<vec>, offset:int, count:int):void
So my answer is, if you are only wrapping for readability, go for it. It's a small, but constant cost. But be very, very careful to change how functions work.
I don't know if there is a big impact for instanciation time, but I will answer your question differently: what are your other options? Do they seem they'll do better?
There is a beautiful benchmark made by Jackson Dunstan about function performance: http://jacksondunstan.com/articles/1820
To sum it up:
closures are expensive
static is slow: http://jacksondunstan.com/articles/1713
overriding, calling a function inside a subClass does not seem to have a big impact
So, if you want to not use inheritance, maybe you'll have to replace it with static calls, and it is bad for performance.
Personally, I'll extend those classes and add an eager instanciation of all objects I'll need at runtime: if it is big, make a beautiful loading screen...
Also, take a look at post bytecode optimizations such as apparat: http://code.google.com/p/apparat/
I don't think that extending will impact the performance a lot. Yes, there is some cost, but it's not so high as long as you don't use composition. I.e. instead of extending Box2d classes directly, you create an instance of that classes and work with it inside your class. For example this
public class Child extends b2Body {
public function Child() {
// do some stuff here
}
}
instead of this
public class Child {
private var _body:b2Body;
public function Child() {
...
_body = _world.CreateBody(...);
...
}
}
I guess you know that as less objects as you create the better. As long as you keep the number of created instances you will have same performance.
From another point of view:
a) adding one more layer of abstractions may change the Box2d a lot. If you work in a team this may be an issue, because the other developers should learn your naming
b) be careful about Middle Man code smell. Usually when you start wrapping already existing functionality you end up with classes which are just delegators.
Some great answers here but I'm going to throw my two cents in.
There are two different concepts you have to recognize: when you extend a class and when you implement a class.
Here is an example of extending MovieClip
public class TrickedOutClip extends MovieClip {
private var rims = 'extra large'
public function TrickedOutClip() {
super();
}
}
Here is an example of implementing MovieClip
public class pimpMyClip {
private var rims = 'extra large';
private var pimpedMovieClip:MovieClip;
public function pimpMyClip() {
pimpedMovieClip = new MovieClip();
pimpedMovieClip.bling = rims;
}
public function getPimpedClip() {
return pimpedMovieClip;
}
}
I think you probably do not want to extend these box2D classes but implement them. Here's a rough outline:
public class myBox2DHelper {
private var box2d = new Box2D(...);
public function MyBox2DHelper(stage) {
}
public function makeBox2DDoSomeTrickyThing(varA:String, varB:Number) {
// write your custom code here
}
public function makeBox2DDoSomethingElse(varC:MovieClip) {
// write your custom code here
}
}
Good luck.
I'm trying my best to adhere to some strict design patterns while developing my current code base, as I am hoping I will be working on it for quite a while to come and I want it to be as flexible and clean as possible. However, in trying to combine all these design patterns to solve the current problem I am facing, I am running into some issues I'm hoping someone can advise me a bit on.
I'm working on some basic homebrewn GUI widgets that are to provide some generic click/drag/duplication behavior. On the surface, the user clicks the widget, then drags it somewhere. Having dragged it far enough, the widget will 'appear' to clone itself and leave the user dragging this new copy.
The Prototype design pattern obviously enters the foray to make this duplication functionality generalizable for many types of widgets. For most objects, the story ends there. The Prototype object is virtually an identical copy of the duplicated version the user ends up dragging.
However, one of the objects I want to duplicate has some fairly big resources attached to it, so I don't want to load them until the user actually decides to click and drag, and subsequently duplicate, that particular object. Enter Lazy initialization. But this presents me with a bit of a conundrum. I cannot just let the prototype object clone itself, as it would need to have the big resources loaded before the user duplicates the dummy prototype version. I'm also not keen on putting some logic into the object which, upon being cloned/duplicated, checks what's going on and decides if it should load in these resources. Instead, a helpful person suggested I create a kind of shell object and when it gets cloned, it were to return this more derived version containing the resources allowing for me to both use RAII and lazy initialization.
But I'm having some trouble implementing this, and I'm starting to wonder if I can even do it the way I'm thinking it should be done. Right now it looks like this:
class widgetSpawner : public widget {
public:
widgetSpawner();
~widgetSpawner();
private:
widget* mPrototypeWidget; // Blueprint with which to spawn new elements
};
class widgetAudioShell : public widget {
public:
widgetAudioShell(std::string pathToAudioFile);
widgetAudioShell( const widgetAudioShell& other );
~widgetAudioShell();
virtual widgetAudio* clone() const { return new widgetAudio(*this); };
private:
std::string mPathToAudioFile;
};
class widgetAudio : public widgetAudioShell {
public:
widgetAudio(AudioEngineAudioTrack &aTrack);
widgetAudio( const widgetAudio& other );
widgetAudio( const widgetAudioShell& other );
~widgetAudio();
virtual widgetAudio* clone() const { return new widgetAudio(*this); };
private:
AudioEngineAudioTrack &mATrack;
};
Obviously, this is not workable as the shell doesn't know the object that's using it to derive a new class. So it cannot return it via the clone function. However, if I keep the two inheritance-wise independent (as in they both inherit from widget), then the compiler complains about lack of co-variance which I think makes sense? Or maybe it's because I am again having the trouble of properly defining one before the other.
Essentially widgetAudioShell needs to know about widgetAudio so it can return a 'new' copy. widgetAudio needs to know about widgetAudioShell so it can read it's member functions when being created/cloned.
If I am not mistaken, this circular dependency is there because of my like of using references rather than pointers, and if I have to use pointers, then suddenly all my other widgets need to do the same which I'd find quite hellish. I'm hoping someone who's had their fingers in something similar might provide some wisdom?
I am working on using a real time application in java, I have a data structure that looks like this.
HashMap<Integer, Object> myMap;
now this works really well for storing the data that I need but it kills me on getting data out. The underlying problems that I run into is that if i call
Collection<Object> myObjects = myMap.values();
Iterator<object> it = myObjects.iterator();
while(it.hasNext(){ object o = it.next(); }
I declare the iterator and collection as variable in my class, and assign them each iteration, but iterating over the collection is very slow. This is a real time application so need to iterate at least 25x per second.
Looking at the profiler I see that there is a new instance of the iterator being created every update.
I was thinking of two ways of possibly changing the hashmap to possibly fix my problems.
1. cache the iterator somehow although i'm not sure if that's possible.
2. possibly changing the return type of hashmap.values() to return a list instead of a collection
3. use a different data structure but I don't know what I could use.
If this is still open use Google Guava collections. They have things like multiMap for the structures you are defining. Ok, these might not be an exact replacement, but close:
From the website here: https://code.google.com/p/guava-libraries/wiki/NewCollectionTypesExplained
Every experienced Java programmer has, at one point or another, implemented a Map> or Map>, and dealt with the awkwardness of that structure. For example, Map> is a typical way to represent an unlabeled directed graph. Guava's Multimap framework makes it easy to handle a mapping from keys to multiple values. A Multimap is a general way to associate keys with arbitrarily many values.