There's a runtime overhead of spinning up a bunch of threads that are just going to sit idle waiting for an API response. There are better asynchronous models for that sort of thing.
Even if starting a new thread takes 1ms, that pales in comparison to the 300ms network connection.
On my laptop, thread creation (pthread_create() followed by pthread_detach() takes ~17 microseconds.
When one end of a socket is on the Internet somewhere, connection time is ~80ms. If I start a thread and then have it create a network connection, eliminating the therad spawn overhead couldn't save more than 0.02% (that's two percent of a percent) of the running time, by Amdahl's law.
The effect of thread creation just isn't significant here. If this utility is going to spawn 1,000 simultaneous API connections to twitter, the threads could all be started by the time the first connection succeeds.
(My numbers come from a class assignment where I benchmarked some unrelated stuff, but if you're interested, I can send you the report)
On my laptop, thread creation (pthread_create() followed by pthread_detach() takes ~17 microseconds.
When one end of a socket is on the Internet somewhere, connection time is ~80ms. If I start a thread and then have it create a network connection, eliminating the therad spawn overhead couldn't save more than 0.02% (that's two percent of a percent) of the running time, by Amdahl's law.
The effect of thread creation just isn't significant here. If this utility is going to spawn 1,000 simultaneous API connections to twitter, the threads could all be started by the time the first connection succeeds.
(My numbers come from a class assignment where I benchmarked some unrelated stuff, but if you're interested, I can send you the report)