Back to the main page.

Bug 1351 - checksize in checkconfig takes ages on a grandaverage

Reported 2012-03-01 13:13:00 +0100
Modified 2015-07-15 13:31:27 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 enhancement
Assigned to: Jan-Mathijs Schoffelen
Depends on:
See also:

Jörn M. Horschig - 2012-03-01 13:13:41 +0100

I assume time increases exponentially with the number of subjects and number of preprocessing steps... but it's VERY annoying when just plotting a topo and having to wait for (literally) several minutes because the function cleans up the cfg (of all my 20 subjects, which data underwent already various steps). Can the cfg check be just turned off if the number of desired output arguments is zero? This can dealt with by using nargout. However, e.g. ft_topoplotER is a wrapper around topoplotTFR, thus the wrapping needs to be taken care of additionally (so that nargout matches)

Jan-Mathijs Schoffelen - 2012-03-01 13:19:54 +0100

did you try: global ft_default ft_default.trackconfig = 'off' ?

Roemer van der Meij - 2012-03-01 14:00:11 +0100

Wouldn't it be easier to make sure checkconfig doesn't check single subject cfgs? They all underwent a check during the grandaverage, and nothing has changed after that, so it seems like a legitimate skip no?

Robert Oostenveld - 2012-03-01 16:56:09 +0100

(In reply to comment #1) it ain't about cfg.trackconfig, but about cfg.checksize. If you specify inf, it should not check. (In reply to comment #2) checkconfig does not know about the nature of the cfgs, so would not be able to distinguish a single subject one from any other one. But I can imagine that a solution would be to prevent it from checking too deep into the nested configs, i.e. don't go all the way back into the history. @Jorn: it would be interesting to have your example data in a bug1351.mat file and a test_bug1351.m file with a tic and toc in it.

Jörn M. Horschig - 2012-03-12 17:26:14 +0100

I committed a test script and (a snippet of) data. The data now only features two subjects - I could update it to the full 20 if desired (or write a loop that duplicates data), but I think the issue should be clear when running the data. ... and I just extended the testscript to compute and output some profiling information: Function Time RelativeTime ft_topoplotER 105.27s 100.00% ft_topoplotTFR 103.96s 98.75% ft_postamble 90.69s 86.15% ft_checkconfig 90.40s 85.87% utilities\private\ft_postamble_trackconfig 90.22s 85.70% ft_checkconfig>checksizefun 90.20s 85.69% ft_defaults 3.75s 3.57% ft_hastoolbox 3.52s 3.34% ft_prepare_layout 3.00s 2.85% ft_freqdescriptives 2.58s 2.45% ft_senstype 2.56s 2.44% ft_channelselection 2.45s 2.33% path 2.09s 1.98% ft_filetype 1.61s 1.53% ft_senslabel 1.51s 1.44% ft_plot_topo 1.28s 1.22%

Jörn M. Horschig - 2012-03-12 17:27:30 +0100

oh btw, I call the function 10 times in a row, that's why it takes to long ;)

Eelke Spaak - 2012-03-14 11:08:12 +0100

I tracked the issue down to the cfg.previous.pre(.....)vious.event structure array being processed recursively. I added an explicit check to ft_checkconfig>checksizefun whether a structure is called 'event', in which case, the struct should be checked as a whole, rather than it having its subfields checked for max. size. Also, I added a check whether the entire cfg is larger than max size; if not, don't enter the loop. Fixed in revision 5459.

Eelke Spaak - 2012-08-23 10:35:14 +0200

closing my bugs

Jan-Mathijs Schoffelen - 2015-05-07 11:15:35 +0200

fails on the dashboard, it should be looked into why

Jan-Mathijs Schoffelen - 2015-05-07 11:23:29 +0200

At some point the 'powspctrm' field is missing... The cause seems to be that the data in test_bug1351 is internally inconsistent. size(tmpdata.powspctrm): [842 25 2 2]; numel(tmpdata.label): 15 My hunch is that the stricter checking of internal consistency in data structures causes the issue. Suggested fix: make the data consistent and overwrite....

Jan-Mathijs Schoffelen - 2015-05-07 11:25:40 +0200

@robert: could you at your earliest convenience change the file permissions of bug1351.mat on /home/common/matlab/fieldtrip/data/test? Thanks.

Robert Oostenveld - 2015-05-07 13:36:47 +0200

(In reply to Jan-Mathijs Schoffelen from comment #10) permissions should now be fixed.

Jan-Mathijs Schoffelen - 2015-05-07 13:42:42 +0200