Here are the two important #defines for Max 5 atom_setparse():
#define ATOM_MAX_STRLEN (32768) // largest possible string size for an atom
#define OBEX_UTIL_MAX_ATOM_GETBYTES 1048576
This is to say that you can have input for which each individual atom should not be larger than 32k single byte characters, and that the entire string should contain no more than ~1 million atoms. Otherwise each atom will be truncated at 32k and the entire list will be limited at 1 million atoms.
Lists which are passed around between max objects are practically limited to 32k atoms, though not every object supports processing 32k atom lists.
BTW, a colleague pointed out that this definition of OBEX_UTIL_MAX_ATOM_GETBYTES as 1048576 is not part of the public SDK and is restricted to being used by the kernel (which actually merges the use of getbytes and sysmem_newptr in Max 5’s unified memory pool). In the public headers it is defined to be 4095 to conform to the legacy getbytes() short argument.
You probably want to avoid using this macro for anything.
However, those details aren’t particularly important to the question. The important thing is that internally atom_setparse is restricted to ~1 million atoms, each atom having a maximum of 32k characters.
Thanks for the clarification. 2^20 Atoms ain’t too shabby!
Just out of curiosity: has anyone ever tried the performance with parsing a gigabyte string with atom_setparse()? Seems like that might eat just a few cycles. But it’s nice to know that much memory is available.