Back to the main page.
Bug 738 - ft_read_event and ft_read_data have to be made faster
| Status | CLOSED FIXED |
| Reported | 2011-06-07 14:19:00 +0200 |
| Modified | 2014-02-24 10:56:41 +0100 |
| Product: | FieldTrip |
| Component: | realtime |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | 1773 |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-06-07 14:19:41 +0200
On 6 Jun 2011, at 13:07, Philip van den Broek wrote: PS: ook het sorteren van de events aan het einde van de functie ft_read_event is ook een reden om ft_buffer te gebruiken omdat alleen de laatste (nieuwste binnengekomen) events verwerkt moeten worden. Hoi Robert, Ik begrijp je standpunt, voor mij is de belangrijkste reden voor het gebruik van ft_buffer de efficiëntie van de code (zo snel mogelijk naar de aanroep buffer('GET_HDR', ... ) of buffer('GET_EVT', ... ). De functies ft_read_header en ft_read_event controleren eerst alle opties en dit kost op mijn machine bijvoorbeeld minimaal 3 ms extra t.o.v. het gebruik van ft_buffer. Is er een optie in de aanroep van deze functies mogelijk die de controles overslaat (in een online setting hoeven ze niet iedere keer gecontroleerd te worden). Alhoewel 3 ms op zich weinig is, beïnvloedt het de performance in een online setup wel nadelig vanwege het aantal keren dat de aanroep gedaan wordt. Ik denk dan bijvoorbeeld aan: ft_read_data/header('buffer://localhost:1972','poll'), (the 'poll' option to indicate skipping the additional option checks) voor het huidige aantal samples/events, of ft_read_data/header(...,'poll','blocking',true/false,'timeout',0.1), als je de timeout optie wil gebruiken
Robert Oostenveld - 2011-06-07 14:23:03 +0200
The following code demonstrates the problem % start a buffer on the command line like this manzana> cd fieldtrip/realtime/general manzana> ./buffer.maci64 % inititalize it with some data filename = 'buffer://localhost:1972'; hdr = []; hdr.Fs = 1000; hdr.nChans = 10; ft_write_data(filename, [], 'header', hdr); for i=1:100 event = []; event.sample = i; event.value = 1; event.offset = 0; event.duration = 0; event.type ='trigger'; ft_write_event(filename, event); end % read from the buffer, this should be made faster ft_read_event(filename)
Robert Oostenveld - 2011-06-07 14:30:01 +0200
it only runs slow on the first call when all functions have to be compiled in memory >> tic; ft_read_event(filename); toc Elapsed time is 0.330049 seconds. >> tic; ft_read_event(filename); toc Elapsed time is 0.015560 seconds. >> tic; ft_read_event(filename); toc Elapsed time is 0.005377 seconds. >> tic; ft_read_event(filename); toc Elapsed time is 0.005958 seconds. >> tic; ft_read_event(filename); toc Elapsed time is 0.006223 seconds.
Robert Oostenveld - 2011-06-07 14:30:21 +0200
Created attachment 67 screenshot with profiling details
Robert Oostenveld - 2011-06-07 14:44:59 +0200
I replaced the ismember is any(strcmp(...)) which is much faster and I switched to ft_getopt (which is a mex file) instead of keyval. @Philip: Could you check whether the speed is now acceptable for you?
Philip van den Broek - 2011-06-10 10:53:01 +0200
De resultaten hieronder laten zien dat via ftb=ft_buffer(filename) en ftb.poll() resultaten veel sneller beschikbaar komen. Ik ben nog niet overtuigd dat dit met de twee benodigde aanroepen van ft_read_header (nsamples) en ft_read_event te benaderen is omdat sowieso ft_read_event altijd alle events inleest en dit is voor polling niet nodig. Daarnaast geeft ft_read_header niet het aantal events terug en is dan voor polling (informatie over aantal binnengekomen events in buffer sinds start buffer) niet bruikbaar, tenzij event.number een nieuw veld wordt in de event structure. Ik zou toch graag een efficiente poll functionaliteit behouden, is het een optie om ft_read_header(filename,'poll',varargin) hetzelfde te laten doen als ftb.poll(varargin)? >> tic,for n=1:100,ft_read_header(filename);end,toc Elapsed time is 0.152558 seconds. >> tic,for n=1:100,ft_read_header(filename);end,toc Elapsed time is 0.151979 seconds. >> tic,for n=1:100,ft_read_event(filename);end,toc Elapsed time is 0.380948 seconds. >> tic,for n=1:100,ft_read_event(filename);end,toc Elapsed time is 0.380295 seconds. >> tic,for n=1:100,ftb.poll();end,toc Elapsed time is 0.017608 seconds. >> tic,for n=1:100,ftb.poll();end,toc Elapsed time is 0.017382 seconds. >> ft_read_event(filename) ans = 1x100 struct array with fields: type value sample offset duration >> ftb.poll() ans = nsamples: 0 nevents: 100 >>
Robert Oostenveld - 2011-06-16 14:18:14 +0200
I just committed the change (i.e. blocking in ft_read_event). This was accidental, and the svn log message does not mention it. I don't believe it breaks anything so I won't revert.
Robert Oostenveld - 2014-01-17 08:53:01 +0100
I am cleaning out bugzilla, I believe nothing remains to be done here.