Hi Faberdahl87! Welcome to the NodeBox community.
Adding ram or updating CPU/GPU might help a bit (I'm not sure how much). But I'm afraid working at big size can be slow on NodeBox.
Since NodeBox is entirely vector-based the number of pixels shouldn't matter per se - until you render an animation (at which point those vectors get turned into pixels). You can scale down animation canvas size to help there. If I am doing a lot of complex animation renders I sometimes reduce complexity while working on it, then ramp things up for the final render.
But usually, of course, you end up using big pixel canvas size because you have a lot of complex content. For me, if I am importing data in CSV files, things start to bog down around 100,000 rows or so (half a million rows will usually bring things to a halt). Things will also bog down if I have 1000s of characters of text. Each character is a fairly elaborate text path and those vectors add up.
There are a number of things you can do to combat this, short of upgrading your machine.
First, look for performance bugs. A "performance bug" is a node which apparently producers the correct result, but takes much longer to do than it should. This can easily happen with subnetworks when you set incoming ports to value instead of list.
This happened to me yesterday. I had a subnetwork node which (I thought) was taking in 500 values of one type, 500 values of a second type, and choosing between them to produce 500 outputs. The outputs looked OK, but the node was actually overlaying 500 copies of each vector, a quarter million vectors in all. When I changed the ports from value to list I saw a dramatic speedup.
Another source of slowness is building 50 nodes to do something that can be done with only 2 or 3 nodes. If ever you find yourself laying the same pattern of nodes over and over again like bricks in a long wall, chances are there is a better way of doing things. Typically this will involve replacing that wall of bricks with a single subnetwork.
To check for these things render one node at time and see how long it takes to refresh that node when there is an upstream change. Look at the little red light in the upper right corner. If your node is fast it will barely blink. But if the red light stays on for a full second or more, you might have a slow node.
It's also a good habit to constantly check the data view of your output to see how many paths each node is producing. I could have spotted my example above sooner if I had switched to data view for that node and noticed there were a quarter million paths when I expected only 500.
One final trick. If you are using large input files which you need to filter and manipulate in order to draw things, do as much of your filtering and number crunching as you can upstream. Then use the make_table node to make your own smaller table (or tables) which can drive everything else. THEN save those small tables as CSV files and import them directly instead of the original massive files. Huge time savings for every node thereafter (and for render time of each frame in a movie).
All of this comes with experience and becomes second nature. If you have a project which seems much slower to you than it should be, and if you are willing to share it, post it with a cry for help. I can have a look at it and see if there are any obvious changes that would speed things up. This is especially helpful when you are first starting out.
And if you make something cool or odd or even an interesting disaster please consider sharing it in the "Show Your Work" forum. It's endlessly fascinating to see what others are doing with NodeBox.
Happy creating!
John