any comments about a cache design?

--------------------------------------------------------------------------------

Hello everyone,


I am going to design a Cache in C/C++ (memory cache). I have two different approaches to design/implement it, any comments will be appreciated.

Design 1, using a map (hashtable) to store key --> object pointer relationship (simple and straight forward);

Design 2, store real object or object pointer in a stack/linked list/queue/array as an internal storage data structure, then using a map (hashtable) as an external interface to mapping key --> index in the stack/linked list/queue/array; (in this design, when accessing an object, we need two times mapping, first mapping key to index in the stack/linked list/queue/array, then using the index to access the real object)

I am wondering any advantages or disadvantages of the two designs. Any better design approach suggestion will be appreciated.


thanks in advance,
George

What are you going to be storing in this cache? Is it a malloc() wrapper for something specific?

http://clusty.com/search?query=cache...Mozilla-search

Thank you itsme86,

Quote:

---

Originally Posted by itsme86

What are you going to be storing in this cache? Is it a malloc() wrapper for something specific?

---

It is customer structure from malloc or something. Any comments about the two designs?


regards,
George

Quote:

---

Originally Posted by Salem

http://clusty.com/search?query=cache...Mozilla-search

---

Any advertisements ... Any useful stuff to recommend?


regards,
George

> Any useful stuff to recommend?
None at all.

Try stuff out and work out which is best for you.

How modern x86 processors cache your app's memory is too unpredictable to make a judgement about which is going to be better.
The big advantage to having your objects in a stack/queue is that you'll have your objects stored sequentially which can be a big benefit if you're using an architecture such as the cell.

Repeating what salem said, just run some tests and see which performs better; you should never go strictly by theoretical values.