Self Implemented Hash Map Performance

I have written two hash map implementations, one that stores Vertices and one that stores self implemented vectors of Edges.
They are all fully functioning, however in my application they are quite slow and was hoping if anyone could point out how to improve their speed.

Vertex Hash Map

```
public class VertexHashMap
{
public double noofitems;
public Vertex[] data;
int resize;

public VertexHashMap(int initlen)
{
noofitems=0;
data=new Vertex[initlen];
this.resize = 67;
}

public void AddItem(Vertex value)
{
if ((noofitems/data.length) > 0.7)
{
resize();
}
int index=value.city % data.length;
boolean inserted = false;
int increment = 1;
do
{
if (data[index] == null) {
data[index]=value;
noofitems++;
inserted = true;
}
else {
index+= (increment<<4);
index = index % data.length;
}
} while (!inserted);
}

public Vertex GetValue(int key)
{
int index=key % data.length;
boolean found = false;
int increment = 1;
do
{
if (data[index].city == key)
return data[index];
else if (data[index] == null)
return null;
else {
index+= (increment<<4);
index = index % data.length;
}

} while (!found);
return null;
}

private void resize()
{
//long time = System.nanoTime();
Vertex[] newData = new Vertex[data.length * resize];
resize = 11;
for (Vertex oldMap1 : data) {
if (oldMap1 != null) {
int index = oldMap1.city % newData.length;

Naming Conventions

public double noofitems;

When I first read this, I wondered what a noof was. Then I realized that you were using No. as an abbreviation for number. Why not write it out? It's a few more letters but much clearer.

Elsewhere you use StudlyCaps for class names, which conforms to the Java standard. The accompanying standard for variable and field names would be camelCase, so numberOfItems.

I might have called this count, which is shorter and more consistent with other classes.

this.resize = 67;

As a general rule, methods are verbs while classes, objects, fields, and variables are nouns. Resize is a verb, so it doesn't fit this. I might go with resizeMultiplier.

Hashing collision resolution

Your collision resolution tends to produce chains. Because it produces the same increment regardless of whether this is the first match or the thirtieth, any collision into a chain has to iterate through all remaining elements in the chain.

Consider using an increasing increment. That way collisions only repeat if they start from the same point. Chains don't merge together.

Write what you mean

boolean inserted = false;
    int increment = 1;
    do
    {                 
        if (data[index] == null) {
            data[index]=value;
            noofitems++;
            inserted = true;
        }                               
        else {
            index+= (increment<<4);
            index = index % data.length;
        }                        
    } while (!inserted);

What you are doing here is iterating through the structure until you find an empty slot. Then you update that slot. So just do that:

int increment = 16;
    while (data[index] != null) {
    {
        index += increment;
        index %= data.length;
        increment += 2;
    }

    data[index] = value;
    numberOfItems++;

This removes a redundant branching operation and an unnecessary variable. I suspect that it would be slightly faster, although I haven't tested it.

Set an initial size

Note that a resize operation reinserts all the existing data. You can avoid this by making the initial data structure the size that it needs to be. This will be much more effective than any kind of efficiency adjustments to the operation.

StackExchange Code Review Q#88411, answer score: 6