Back to the main page.
Bug 298 - create mex file implementation of keyval
| Status | CLOSED WONTFIX |
| Reported | 2010-12-12 11:35:00 +0100 |
| Modified | 2011-02-23 13:51:07 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 486 |
| See also: |
Robert Oostenveld - 2010-12-12 11:35:58 +0100
the keyval function is called very often, and in some cases it adds a significant overhead to the execution time. A mex implementation of keyval would probably be much faster, cutting down the overhead.
Stefan Klanke - 2010-12-15 15:59:48 +0100
I made a MEX replacement, but so far only put it into branches/testing, along with a small test script that measures performance. It seems the MEX file is about 5x faster than the M-file. I did not implement any cashing/hashing yet, since this is also not present in the M-file (contrary to what we discussed in the meeting). We could use uthash to make a hash table out of a cell-array if called with a new argument, and get the index from the hash if we see the same key-value pair (as determined from the pointer address) from than on. Could keep a list of, say, 5 hash tables to allow for alternating calls from different places, but I'm not sure it's really worth it, yet. Also, for the hash-table implementation, it would be good if we could define a maximum string length for the keys. Finally, another speedup would be possible by doing case-sensitive comparisons.
Stefan Klanke - 2011-01-20 14:40:22 +0100
Haven't worked on the implementation since my 2010-12-15.
Robert Oostenveld - 2011-02-13 10:57:31 +0100
keyval will be replaced by ft_getopt, see http://bugzilla.fcdonders.nl/show_bug.cgi?id=486