Table of content
While working with sets in MatLab, I realized that Mathworks' implementations of set operations is much less efficient than it could be. So, I created a tiny toolbox, fully compatible with the standard MatLab's set functions. Yet it provides at least 3 to 10 - fold performance gain. The speed increase was achieved mostly due to the assumption that the arrays passed to the set routines are actually sets. In other words, that they contain a unique and sorted set of numbers (of any data type supported by MatLab). Since, this is anyway usually the case, FastSet can be used almost any time set operations are performed in MatLab.
If interested, read more details about the FastSet toolbox.
Performance issues with MatLab set routines
Even though MatLab provides a comprehensive support for working with sets (union, intersect, setdiff and setxor)
What is GUID?
GUID, a Global Unique IDentifier is a 128-bit number used in Windows to identify software components. These numbers are generated from a number identifying the generating computer (to ensure the same number is not produced elsewhere) and time (to prevent generation of identical number on the same machine. MAC address is usually used as the computer-identifying parameter.
If you only need one GUID number, you could generate one on-line or use guidgen.exe - a a small utility available from Microsoft. However, if you need to generate GUID programmatically, you'll have to use Win32 API which is not a fun in such environments as MatLab. So, I created a small mex-file, mexCreateGUID, which does just that.
The archive mexCreateGUID contains versions for 32-bit MatLab and for x64.
The file is quite fast. If called in a loop, it can generate 1 million GUIDs in ~3.5 seconds (on Intel Core 2 Duo EE)
This section may be important to those, writing or using mex-files which implement (really) deep recursions. There is nothing special about mex-files - they are typical executable (DLL) and in principle, you can encounter similar problems with your own code. Then, this section is for you as well
When MatLab encounters stack overflow, it just closes with no notification. Consequently, it's very difficult to spot the problem. Other Windows applications typically crash but report "0xC00000FD: Stack overflow".
Why RAM is not the only thing you should care about
In general, there are three types of memory your code uses. The application may crash even if you have plenty of RAM left on your machine.
There is some space allocated by the operating system (OS) for the code itself. There, it keeps the instructions processed by the CPU. This is rarely a problem since the code does not take much.
There is some space allocated by the process for stack. Function variables and some system information are kept in stack. If another function is called, another frame on stack is allocated for that function's local variables. That new frame is freed when the function returns and the previous frame becomes active. In fact, each frame represents local scope. These scopes are nested in exactly the way, the method calls are nested.
The more local variables and nested calls you have, the deeper the
Similarly to any other executable, at its startup MatLab instructs the operating system about the maximal allocatable stack size