0

I have the following struct 

struct vertice_t{
    char city;
    char connectedBy;
    unsigned short airportCost;
    unsigned short primKey;
    int queueIndex;
    struct adjacency_list_t * adjacencyList;
};

struct adjacency_list_t{
    struct adjacency_list_node_t *  first;
    struct adjacency_list_node_t *  last;
};

struct adjacency_list_node_t{
    unsigned short weight;
    struct vertice_t *  vertice;
    struct adjacency_list_node_t * next;
};

When I do sizeof(struct vertice_t) I get the value 24. But I can see by myself that this struct only takes 1 + 1 + 2 + 2 + 4 + 8 = 18Bytes

Why does this happen? Is there anyway I could compress the data in the struct above to make it smaller? This is for a project and I need to reduce the whole memory usage by 30%.

Thanks!

Daniel Oliveira
  • 1,280
  • 14
  • 36
  • 1
    where is the definition of struct adjaceny_list? – Nguai al May 02 '17 at 02:07
  • first, select language. – BLUEPIXY May 02 '17 at 02:08
  • @Nguaial Sorry, I just added it – Daniel Oliveira May 02 '17 at 02:09
  • The answer to why this happens are: 1. padding, 2. a wrong assumption about the size of pointers. You can address the issue with padding by reversing the order of elements: there is no issue with [unnecessary] padding when the members are listed in increasing order of sizes. – Dietmar Kühl May 02 '17 at 02:11
  • Depending on `struct adjacency_list_t` usage, only one pointer is needed. What operations are needed to be done on `struct adjacency_list_t` ? – chux - Reinstate Monica May 02 '17 at 02:14
  • BTW, the definition of `adjacency_list_t` doesn't matter: the member is a pointer to `struct`. The size of the pointer is not affected by its definition. – Dietmar Kühl May 02 '17 at 02:15
  • @DietmarKühl thanks for your help I really appreciate it! I have the members of the struct vertice_t listed in increasing order of sizes (that would make it 18Bytes) But I still get 24B instead of 20B, idk why? – Daniel Oliveira May 02 '17 at 02:17
  • @Dietmar Kühl Although quite common that the pointer size is not affected, it _can_ be affected. A simple example is of a pointer to a function, `struct` and `char` can vary in size. C does not specify that these 3 are the same size pointer. C supports many architectures. – chux - Reinstate Monica May 02 '17 at 02:20
  • @chux I need a pointer to the last element to add new elements to the end of the list in constant time O(1) – Daniel Oliveira May 02 '17 at 02:20
  • 1
    Use `struct adjacency_list_t` that has 1 pointer, to the last element. The last element next member pointer to the first. Access to the first or last is done in O(1) time. Traversing the list is terminated, not when pointer->next is `NULL`, but when `pointer->next == first`. This will halve the size of `struct adjacency_list_t`, although that will not reduce memory by 30%, for that additional ideas are needed. – chux - Reinstate Monica May 02 '17 at 02:25
  • 1
    @chux That´s genius dude! – Daniel Oliveira May 02 '17 at 02:28
  • 1
    @DanielOliveira This linked-list can add/access in O(1) from either end. It can delete from the first in O(1). Unlike your original list, which can also delete from the end in O(1), this takes O(n) to delete from the end. So as long as you are only deleting from one end, it is a viable efficient alternative. – chux - Reinstate Monica May 02 '17 at 02:35
  • @chux I was able to make on last optimization and reduce the memory needed for more than 30%. On the struct vertice_t instead of having a pointer to the struct adjacency_list_t I included this last struct inside vertice_t, that made me save more 8bytes! – Daniel Oliveira May 02 '17 at 03:31
  • `sizeof` is not a function, so it doesn't "return" anything. It evaluates to a value that is different than the sum of the components, but is exactly equal to the size of the struct. – William Pursell May 02 '17 at 04:43

0 Answers0