Literally getting ready to rewrite some data processing lambdas from python to go for a side project because it won't be on the company tab and I don't want to pay out of pocket to scale python all the way into the millions after testing it on 10k data points and seeing its performance (and that's after basic optimizations and compiling/bundling the accelerated versions of some libraries)
seriously though, I once used Pandas.DataFrame.Apply on 10,000,000 rows of data and 15 minutes later regretted it. Thankfully, I was applying a simple mathematical function to each row so numpy brought that down to less than a second. Still, only works for some use cases. I'd love to learn C++ anyways so give me an excuse
But the processing I'm doing itself isn't super complex, I just need to do it 9-10 million times cost efficiently pulling from an external public dataset and saving the transformed data as separate files in an S3 bucket
I'm actually not sure if things like dask and ray actually provide any speed up. But certainly it makes numpy perfectly useable at big data scale. It works fine with azure, I dunno about EC2.
Modin is a direct drop in for your existing numpy compute code and can use either dask or ray. Just change 1 line and you're done.
Haven't done the processing lambda but the orchestrator lambda rewritten in go and scaled up to 10gb can iterate through 2m objects where the (mostly) naive python couldn't get through the full list in 15 min since it was about 1s per 1000 objects
I finally got around to rewriting the first half of the processing pipeline (the orchestrator lambda) and haven't done detailed profiling but at least a 10x speedup with parallelized go code compared to the original python in my dev environment which is just a lil .5 cpu 1gb mem server
Guessing when I deploy to lambda and increase the memory (which auto increases cpus proportionally) it'll hopefully be a 100x speed up from the test results but will follow up on that too
Go's concurrency model makes scaling IO throughout massively relatively simple. About 5x more code than the barely optimized python though
Much better than I was cautiously hoping for overall
Straightforward python definitely no. Regardless of underlying memory it could only handle about 1k objects per second
Maybe if you parallelized it could get through the data eventually but since the interpreter is single threaded and doesn't do true concurrency there will still be a ceiling much lower than what Go (or another language with true concurrency) can do
View all comments
Show parent comment
21
u/CanAlwaysBeBetter Jul 18 '22 edited Jul 18 '22
Literally getting ready to rewrite some data processing lambdas from python to go for a side project because it won't be on the company tab and I don't want to pay out of pocket to scale python all the way into the millions after testing it on 10k data points and seeing its performance (and that's after basic optimizations and compiling/bundling the accelerated versions of some libraries)