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