The length of the salt is not important once it has exceeded the minimum below which pre-calculation becomes cheap.
To quote Wikipedia:
Early Unix implementations limited passwords to 8 characters and used
a 12-bit salt, which allowed for 4,096 possible salt values. This was
an appropriate balance for 1970s computational and storage costs.
By my math, a 12-bit salt means someone could pre-compute rainbow tables for all 4096 salts; assuming a 7-8 character password, all it takes is 16 petabytes... certainly not out of the reach of many well-funded attackers today. Modern cryptographic algorithms tend toward 8- to 32-character salts in order to raise the bar (see table 2 here).
But I believe the length of the salt does not, for example, meaningfully impact the speed of each password calculation*. The choice of a good password algorithm will slow computations and lower the speed at which an attacker can mount a brute force attack; whether that algorithm is getting +8 characters of input is not going to make a significant difference compared to +16 characters or +32.
So as long as the salt isn't so small as to make pre-computation feasible, it's doing half of it's job. (The other half is to prevent Alice and Bob from having the same hash if they have the same password).
*That's my belief... but I'm not a mathematician or a crypto coder. Take that statement with a grain of, well, you know...