@User xschem is very small and has a low footprint. However normally you will not use a schematic for a SoC or a Microprocessor, because these things are designed with a 'verilog (or more in general a RTL description) to layout' flow, where logic synthesis tools, static timing analyzers, memory generators, standard cell placement and routing tools (and many other tools in the chain) allow you to produce a complete layout. Schematic editors are more used for analog design, for creating analog blocks (RF, voltage regulators, charge pumps, PLLs, ADC/DACs etc) for block prototyping, new ideas exploration, or for creating a high level description of blocks interconnected together, each one in turn described with some RTL or transistor level implementation. Anyway, i have imported a synthetyzed module from spice netlist, (Thank you @User) containing 50K gates and 200K elements (including wires, net labels etc) (such blocks are normally not imported in a schematic). Xschem required 160MB virtual memory and 130MB resident set to load and handle the circuit. My system is a simple laptop with 4GB ram, but i am not supposed to run a full RTL2LAYOUT flow on this. This imported block was used to do a clock tree inspection, to verify fanout and buffering, however there are tools that do this task automatically, so this import was more a stress test for xschem :-)

Thats good to know. Even I am working on a 4GN ram system and things are running for now. What about when a high frequency simulation or infact a modulated signal is used. One needs to run long and in small steps. Doesn't that need more memory. Whats the OS that you are using. I see it as linux type ( in the tutorial) but not sure which.

I am using Linux Devuan, it's a variant of Debian. I think for EDA work all linuxes are similar. Xschem has been succesfully ported to MacOS (using the XQuartz x11 server) , on CentOS (various versions) on Ubuntu and various Debian machines on Intel and Arm cpus. For Windows i don't know, many windows users just use a WSL subsystem runing linux. Xschem has a working windows port, however the main system for xschem is Unix/Linux. For High frequency simulations the limiting factor is probably not RAM but the speed of CPU. You can gain probably a factor of ~2 if you use OpenMP, splitting the simulation load on more processor threads, you gain more if you simulate many different process corners, you simply distribute the tasks on different cores, but for one single transient time simulation you can not have any additional benefit from parallel computing .

@Stefan Schippers Thanks for the info. I will try to move to the pre-master branch for ngspice.