A Memory-Efficient Doubly Linked List
In the quest to make small devices cost effective, manufacturers often need to think about reducing the memory size. One option is to find alternative implementations of the abstract data types (ADTs) we are used to for our day-to-day implementations. One such ADT is a doubly linked list structure.
In this article, I present a conventional implementation and an alternative implementation of the doubly linked list ADT, with insertion, traversal and deletion operations. I also provide the time and memory measurements of each to compare the pros and cons. The alternative implementation is based on pointer distance, so I call it the pointer distance implementation for this discussion. Each node would carry only one pointer field to traverse the list back and forth. In a conventional implementation, we need to keep a forward pointer to the next item on the list and a backward pointer to the previous item. The overhead is 66% for a conventional node and 50% for the pointer distance implementation. If we use multidimensional doubly linked lists, such as a dynamic grid, the savings would be even greater.
A detailed discussion of the conventional implementation of doubly linked lists is not offered here, because they are discussed in almost every data structure and algorithm book. The conventional and the distance pointer implementations are even used in the same fashion to have comparable memory and time usage statistics.
We define a node of pointer distance implementation like this:
typedef int T;
typedef struct listNode{
T elm;
struct listNode * ptrdiff;
};
The ptrdiff pointer field holds the difference between the pointer to the next node and the pointer to the previous node. Pointer difference is captured by using exclusive OR. Any instance of such a list has a StartNode and an EndNode. StartNode points to the head of the list, and EndNode points to the tail of the list. By definition, the previous node of the StartNode is a NULL node; the next node of the EndNode also is a NULL node. For a singleton list, both the previous node and next node are NULL nodes, so the ptrdiff field holds the NULL pointer. In a two-node list, the previous node to the StartNode is NULL and the next node is the EndNode. The ptrdiff of the StartNode is the exclusive OR of EndNode and NULL node: EndNode. And, the ptrdiff of the EndNode is StartNode.
The insertion and deletion of a specific node depends on traversal. We need only one simple routine to traverse back and forth. If we provide the StartNode as an argument and because the previous node is NULL, our direction of traversal implicitly is defined to be left to right. On the other hand, if we provide the EndNode as an argument, the implicitly defined direction of traversal is right to left. The present implementation does not support traversal from the middle of the list, but it should be an easy enhancement. The NextNode is defined as follows:
typedef listNode * plistNode;
plistNode NextNode( plistNode pNode,
plistNode pPrevNode){
return ((plistNode)
((int) pNode->ptrdiff ^ ( int)pPrevNode) );
}
Given an element, we keep the pointer difference of the element by exclusive ORing of the next node and previous node. Therefore, if we perform another exclusive OR with the previous node, we get the pointer to the next node.
Given a new node and the element of an existing node, we would like to insert the new node after the first node in the direction of traversal that has the given element (Listing 1). Inserting a node in an existing doubly linked list requires pointer fixing of three nodes: the current node, the next node of the current node and the new node. When we provide the element of the last node as an argument, this insertion degenerates into insertion at the end of the list. We build the list this way to obtain our timing statistics. If the InsertAfter() routine does not find the given element, it would not insert the new element.
Listing 1. Function to Insert a New Node
void insertAfter(plistNode pNew, T theElm)
{
plistNode pPrev, pCurrent, pNext;
pPrev = NULL;
pCurrent = pStart;
while (pCurrent) {
pNext = NextNode(pCurrent, pPrev);
if (pCurrent->elm == theElm) {
/* traversal is done */
if (pNext) {
/* fix the existing next node */
pNext->ptrdiff =
(plistNode) ((int) pNext->ptrdiff
^ (int) pCurrent
^ (int) pNew);
/* fix the current node */
pCurrent->ptrdiff =
(plistNode) ((int) pNew ^ (int) pNext
^ (int) pCurrent->ptrdiff);
/* fix the new node */
pNew->ptrdiff =
(plistNode) ((int) pCurrent
^ (int) pNext);
break;
}
pPrev = pCurrent;
pCurrent = pNext;
}
}
First, we traverse the list up to the node containing the given element by using the NextNode() routine. If we find it, we then place the node after this found node. Because the next node has pointer difference, we dissolve it by exclusive ORing with the found node. Next, we do exclusive ORing with the new node, as the new node would be its previous node. Fixing the current node by following the same logic, we first dissolve the pointer difference by exclusive ORing with the next current node. We then do another exclusive ORing with the new node, which provides us with the correct pointer difference. Finally, since the new node would sit between the found current node and the next node, we get the pointer difference of it by exclusively ORing them.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Dart: a New Web Programming Experience
- Developer Poll
- What's the tweeting protocol?
- May 2013 Issue of Linux Journal: Raspberry Pi
- Reply to comment | Linux Journal
3 hours 22 min ago - Reply to comment | Linux Journal
4 hours 9 min ago - Web Hosting IQ
5 hours 43 min ago - Thanks for taking the time to
7 hours 19 min ago - Linux is good
9 hours 17 min ago - Reply to comment | Linux Journal
9 hours 34 min ago - Web Hosting IQ
10 hours 4 min ago - Web Hosting IQ
10 hours 5 min ago - Web Hosting IQ
10 hours 6 min ago - Reply to comment | Linux Journal
13 hours 6 min ago




Comments
Worst. Linked List. Ever.
Worst. Linked List. Ever.
This is an interesting
This is an interesting article. A criteria of a linked list is that any node by be unlinked from the list in O(1). Exclusive-or method requires history to move ahead similar to how parity is calculated. Thus, we must call this a memory efficient queue instead. The memory efficient queue is a nice technique to use in embedded systems.