Why does my Neo4J Text Index have no Impact on query performance?

I have created a simple neo4j graph, and am testing the impact of indexing along a property, and am struggling to understand why the index, which appears to be used and functioning, is not improving read-only query performance.

Graph And Index Creation Details:

There are 2 types of node labels (src_node, and tag) and each node has a single text property, respectively src_prop and tag_str.

I create a simple index over the tag_str property on the "tag" nodes.

"CREATE TEXT INDEX `tag_idx` FOR (n:`tag`) ON (n.`tag_str`)

I create 1000 tag nodes, each with a randomly generated tag_str value that is 8 characters long.

e.g. CREATE (:tag {tag_str:"A1B2C3D4"})

I create 100000 source nodes, each with a str_prop that is a random string of length 32,
each of these are linked to a single tag, with an edge labeled "contains"

MATCH (tgt:tag WHERE tgt.tag_str= "A1B2C3D4") CREATE (:src_node{src_prop:<32_char_string>})-[:contains]->(tgt)

This all works fine, I can confirm that the links are created.

Find Query

I run a simple query to find nodes linked to a particular tag, as an example

MATCH (tgt:tag WHERE tgt.tag_str = "asEQqNLF") - [] - (retnode) return retnode

I can look at the index stats, and verify that it is being read when this query is run.

When I compare the indexed vs non-indexed runs, the indexed performance for the find queries (not the src_node creation queries) is either identical or slightly worse. I am struggling to understand why, so would appreciate any insights folks might have.

e.g. am I creating an incorrect type of index? Am I bottlenecked in another part of the query such as edge traversal? Is there some configuration I have missed?

CLARIFICATION UPDATE

The timing test is run upwards of 100k times, includes per-transaction time as well as end-to-end timings both with and without the index. I have scaled the size of the graph as well and see similar results, but will continue investigation based on feedback below.

Fixed a minor typo that was existent in post here but not in the actual tests I am referencing.

Some thoughts:

1. 1000 indexed nodes may be too small a number for a significant difference in performance, especially if all the nodes are cached in memory (since scanning such a small number of nodes without an index would be very fast anyway).

2. You cannot arrive at any valid conclusions by comparing the time it takes to execute each operation just once. You need to execute the operations a large number of times.

3. In addition to using the index (or not), your test is also traversing relationship(s) and returning the node(s) at the other end. The amount of time to do that additional work obscures (and may swamp) the time it takes to get the starting node.

A more accurate comparison would be achieved by performing just the operation(s) you wish to compare many times. For example (where $tag_str_list is a parameter of maybe 500 valid tag_str values):

MATCH (t:tag)
WHERE t.tag_str IN $tag_str_list
RETURN COUNT(*) AS cnt