Well I was removing the 'EDITREG' macro from the LSVBITFD ASSEMBLE file and replacing it with a suitable expansion when I found a way to further improve the performance of the thing. A very easy way in fact: most of the nodes in the network are end-nodes, with only one connection to the outer world. By flagging these nodes during the initalization phase as "already queued for re-evaluation" without actually queueing them up the chained list, I was able to save 25 to 30% CPU time. I was amazed - I had thought there were less end-nodes and that consequently the overhead was not that bad, and anyway with the old "wraparound" ( :-) ) heap structure I couldn't avoid it. But apparently this less-than-10-lines change seems to be really worth it. I have compared the results with the old version and they DO match. I'm now down to 0.10 sec CPU on this 4341-12 in the best cases, instead of 0.17 with the heap version (the standard deviation became much more significant since I introduced the list/flag array structure; if the source node is a hub node like CEARN or DEARN or CUNYVM, you get some 0.10; if it's a dead-end node you more CPU). Computers can be VERY surprising when they want to :-) Eric