What about the linux kconf menus?
(`make menuconfig`)

Once menuconfig is compiled, it is executed with a Kconfig file passed
as an argument. It loads the file (and included files) very quickly, and
the Kconfig files are _massive_.

After it loads the file(s), it parses them, then determines what should
be disabled, etc. The whole startup takes less than a second on my
"special" (read: slow) computer, IIRC.

The whole program is pretty fast, and the Kconfig files are text-based.

Maybe you could do whatever magic the kernel devs did, but with a
different syntax?

On Thu, Aug 04, 2016 at 02:36:06PM -0400, Steve Litt wrote:
>The last two items on the preceding list are why deployment is so
>problematic. On my system, each of my 237 submenus requires its
>own .mnu (menu description) file. These are created by compiling,
>through a program I wrote, a 4122 line s.emdl file. That compile lasts
>over 2 seconds, which is why running a menu system directly off an EMDL
>file can't happen. You see, every time you invoke a submenu, you invoke
>a brand new UMENU executable. This works well, it eliminates the need
>for a stack or client/server or the like, and it's trivially simple.
>But it means that each and every invocation of umenu must load and
>display in a fraction of a second.
>
>About menu system configuration: Chances are, I'll never find a native
>format for the menu system configuration that is both: 1) lightning
>quick on submenu startup, and 2) Lightning quick for a person to
>modify, including moving whole branches.

-- 
 _________________________________________________
( Knowing just enough to be dangerous since 1998. )
 -------------------------------------------------
        o   ^__^
         o  (--)\_______
            (__)\       )\/\
                ||----w |
                ||     ||