Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Are HashMaps bad for Entity-Component-System Architectures?  (Read 2763 times)
0 Members and 1 Guest are viewing this topic.
Offline Nausica
« Posted 2014-05-06 16:42:09 »

My ECS uses HashMaps to represent Components and their features, and each Entity has a HashMap that contains components.  Every time a component is added, it generates a String tag that is attached to the Entity, which each System checks for to make sure the component actually exists for said Entity.

I was reading up the Artemis info and they say that HashMaps are bad data structure. Is it? Since my design uses a HashMap container to store multiple HashMaps, is there a more efficient way that I should be doing this, or should I only worry about it if performance is a big problem?
Offline trollwarrior1
« Reply #1 - Posted 2014-05-06 16:50:45 »

From my experience (I might be 100% wrong) hashmaps is like the slowest storing method. Fastest is an array, then come lists, and after that the hashmap.
Offline Nausica
« Reply #2 - Posted 2014-05-06 17:13:53 »

ah Sad Would it be possible to create an enum to represent a global index that I can use to refer to components and their parts? The main reason I used HashMap was because of the ease-of-use of the Key-Value system
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 516



« Reply #3 - Posted 2014-05-06 17:23:32 »

Is there a limit on the number of components a container can hold?
Offline trollwarrior1
« Reply #4 - Posted 2014-05-06 17:25:06 »

ah Sad Would it be possible to create an enum to represent a global index that I can use to refer to components and their parts? The main reason I used HashMap was because of the ease-of-use of the Key-Value system

You can just write a getter method for ease of use.
Offline junkdog
« Reply #5 - Posted 2014-05-06 18:23:06 »

Most ECS frameworks have some sort of array-like data structure per component type. In artemis each entity is given an integer id: the id represents the index at which the component is stored.

Unless you have a lot of entities, you probably won't see a noticeable performance hit (ofc depends on platoform, entity count, GC and so forth). One of the ideas behind ECS, besides reducing complexity as the project grows, is performance: if all instances of ComonentX are aligned in memory, you'll get faster memory access (better cache locality), but java doesn't easily lend itself to contiguous memory layout when it comes to objects.

edit: If entities hold on to their own components, how do you get all entities matching a specific component composition?
edit 2: If you want to stick with your current approach - consider using the component's class as key and replacing the HashMap with IdentityHashMap - getClass() always returns the same object per class.

artemis-odb: bugfixing and performance optimized fork of artemis ECS
Offline delt0r

JGO Wizard


Medals: 139
Exp: 18 years


Computers can do that?


« Reply #6 - Posted 2014-05-06 18:26:41 »

HashMaps can be very fast. In many cases as fast as and array. The random access can hurt somethings. But mostly don't worry about. If you don't have some profiling results showing that your maps are your problem, don't don't optimize it. And if it did become a problem there are a number of alternatives from java.util. that can just be dropped in.

If you want key value lookup. Just use a hash table.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline ags1

JGO Kernel


Medals: 356
Projects: 7


Make code not war!


« Reply #7 - Posted 2014-05-06 18:29:08 »

Don't forget the TreeMap... should give slower insert and faster read.

In my ECs I just put everything in a list and iterate. I have specific methods to get at the commonly used properties.

Offline Nausica
« Reply #8 - Posted 2014-05-06 18:32:18 »

Most ECS frameworks have some sort of array-like data structure per component type. In artemis each entity is given an integer id: the id represents the index at which the component is stored.

Unless you have a lot of entities, you probably won't see a noticeable performance hit (ofc depends on platoform, entity count, GC and so forth). One of the ideas behind ECS, besides reducing complexity as the project grows, is performance: if all instances of ComonentX are aligned in memory, you'll get faster memory access (better cache locality), but java doesn't easily lend itself to contiguous memory layout when it comes to objects.

edit: If entities hold on to their own components, how do you get all entities matching a specific component composition?

Each entity has a tag container. Each system checks if the Entity has the required tags, then performs the methods on the components that exist.

Is there a limit on the number of components a container can hold?

No. But there are different variants of components, and the entity can only have one type of variant


You can just write a getter method for ease of use.

I have a fetch method that I use to pull data from the components of a specific entity. When I looked at it recently I thought it would work just as fine if I used an Object[] instead of HashMaps
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 485
Exp: 7 years



« Reply #9 - Posted 2014-05-06 18:50:09 »

I know it can never be said enough, and will never be said enough, but:

Don't optimize until you need to optimize.
How do you know you need to optimize?
The profiler will tell you.



Chances are a HashMap is plenty fast. And if it's not, then the first thing you should do is try not using Strings, but Integers instead or something. (compare String.hashCode() vs. Integer.hashCode())

And if it's still not good enough, the HPPC library should have you covered for speed while still letting you use your nice Maps.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen

JGO Kernel


Medals: 516



« Reply #10 - Posted 2014-05-06 19:38:39 »

Quote
Quote
Is there a limit on the number of components a container can hold?

No. But there are different variants of components, and the entity can only have one type of variant
So it "component by (variant) type" instead of straight type or name?  If so then obviously there can only be a finite number of variants.  What's your projected upper limit?
Offline Nausica
« Reply #11 - Posted 2014-05-06 23:32:21 »

Quote
Quote
Is there a limit on the number of components a container can hold?

No. But there are different variants of components, and the entity can only have one type of variant
So it "component by (variant) type" instead of straight type or name?  If so then obviously there can only be a finite number of variants.  What's your projected upper limit?


Well not every component has a variant. The only components that currently have variants are the Renderer and Logical components, since different entities could use different rendering methods, or have different logical steps. But there is no real limit to all of the other components.
Offline Roquen

JGO Kernel


Medals: 516



« Reply #12 - Posted 2014-05-07 07:09:31 »

Then you're stuck with hashing.

(EDIT: well assuming that the lookup probabilities are roughly equal per contained type)
Pages: [1]
  ignore  |  Print  
 
 

 
xxMrPHDxx (21 views)
2017-11-21 16:21:00

xxMrPHDxx (14 views)
2017-11-21 16:14:31

xxMrPHDxx (16 views)
2017-11-21 16:10:57

Ecumene (114 views)
2017-09-30 02:57:34

theagentd (150 views)
2017-09-26 18:23:31

cybrmynd (259 views)
2017-08-02 12:28:51

cybrmynd (250 views)
2017-08-02 12:19:43

cybrmynd (247 views)
2017-08-02 12:18:09

Sralse (260 views)
2017-07-25 17:13:48

Archive (880 views)
2017-04-27 17:45:51
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!