The performance of a simple PV snapshot application

In order to check the impact of programming style, synchronous and asynchronous, on the performance of a PV snapshot, I set up a simple benchmark and tested it with five different implementations. The benchmark is a snapshot to get the current value of (1) 97 connected PV's, (2) 97 connected and 4 disconnected PV's, and (3) 97 connected and 15 disconnected PV's. Four implementations is programmed with Python and pyepics library. The last one is programmed with node.js and it gets the PV value via system caget command line tool. All the implementations are on github.

The pv and ca implementations are based on the suggestions by pyepics developers. The improvement is huge when all the PV's are connected. For 97 PV's, the time required drops from about 2700 milliseconds to about 200 milliseconds. However, they do not perform good when there are disconnected PV's. In the programs, I set all the connection timeout to be 1 second. The pv version program takes extra 2 seconds for each disconnected PV and the ca version program takes extra 1 second for that. The major part of the pv version is

	start = time.time()
	for pv_name in pv_list:
	pv = PV(pv_name)
	if pv.wait_for_connection(timeout=1.0):
	result[pv_name] = pv.get(use_monitor=False)
	else:
	result[pv_name] = 'not connected'
	duration = time.time() - start
	print int(round(duration * 1000))

view raw snapshot_pv.py hosted with ❤ by GitHub

The major part of the ca version is

	start = time.time()
	for pv_name in pv_list:
	ch = ca.create_channel(pv_name, connect=False, auto_cb=False)
	result[pv_name] = [ch, None, None]
	for pv_name, data in result.items():
	result[pv_name][1] = ca.connect_channel(data[0], timeout=1.0)
	ca.poll()
	for pv_name, data in result.items():
	if result[pv_name][1]:
	ca.get(data[0], wait=False)
	ca.poll()
	for pv_name, data in result.items():
	if result[pv_name][1]:
	val = ca.get_complete(data[0])
	result[pv_name][2] = val
	else:
	result[pv_name][2] = 'not connected'
	duration = time.time() - start
	print int(round(duration * 1000))

view raw snapshot_ca.py hosted with ❤ by GitHub

Threading should improve the situation by waiting for the timeout in parallel rather than in sequence. However, the overheads of creating processes and sharing state between processes are also enormous. The major part of the multi-threading pv version is

	# ...
	from multiprocessing import Process, Manager
	def get(d, pv_name, size, start, pid):
	pv = PV(pv_name)
	if pv.wait_for_connection(timeout=1.0):
	d[pv_name] = pv.get(use_monitor=False)
	else:
	d[pv_name] = 'not connected'
	if len(d) == size:
	print int(round((time.time() - start) * 1000))
	os.kill(pid, signal.SIGTERM)
	# ...
	size = len(pv_list)
	manager = Manager()
	d = manager.dict()
	start = time.time()
	pid = os.getpid()
	for pv_name in pv_list:
	p = Process(target=get, args=(d, pv_name, size, start, pid))
	p.start()
	time.sleep(30)

view raw pv_threading.py hosted with ❤ by GitHub

And the corresponding multi-threading ca version is

	def get(d, pv_name, size, start, pid):
	ch = ca.create_channel(pv_name, connect=False, auto_cb=False)
	if ca.connect_channel(ch, timeout=1.0):
	d[pv_name] = ca.get(ch, wait=True)
	else:
	d[pv_name] = 'not connected'
	if len(d) == size:
	print int(round((time.time() - start) * 1000))
	os.kill(pid, signal.SIGTERM)

view raw snapshot_ca_threading.py hosted with ❤ by GitHub

The node.js implementation performs much better than both the pv and ca multi-threading implementations. I think this is because 1) the process in node.js is much lighter than those in python, and 2) there is no shared state between processes in node.js because of the usage of asynchronous callback and closure.

	start = Date.now();
	size = pv_list.length;
	pv_list.forEach(function(pv) {
	ca.exec('caget', pv, function(err, result) {
	complete = complete + 1;
	if (err) {
	results[pv] = {
	name: pv,
	value: 'unavailable'
	};
	} else {
	results[pv] = ca.parseCaget(result);
	}
	if (complete == size) {
	console.log('the snapshot took ' + (Date.now() - start) + ' milliseconds.');
	}
	});
	});

view raw snapshot.js hosted with ❤ by GitHub

On the protocol level, channel access is fully parallel and asynchronous. It seems we should do the same on high-level programming level to leverage that advantage.