Overview

In the previous blog post, we explored how we can use deep learning models to optimize Python's GC calls. In this post, we’ll look at how the model performs with :

• More training data
• More complex parameters
• More epochs
• Different model architectures

System Information

Different Cases

Every model has the same training and evaluation load i.e. locust -f locustfile.py --headless -u 100 -r 10 --run-time 1m unless mentioned otherwise

Case 1 : Complex model

Model architecture is a normal LSTM but with more layers and increased sequence length :

1"lstm": {
2  "input_size": 10,
3  "hidden_size": 64,
4  "num_layers": 10,               // increased this from 2
5  "sequence_length": 100,         // increased this from 10
6  "epochs": 100,
7  "learning_rate": 0.001,
8  "batch_size": 32
9}

Realtime Monitor (pretty 😤) and Raw Results

Case 2: Different model architecture

Here, we change the underlying ML model itself. Again, everything else follows the baseline config

Case 2a. Using normal feed-forward networks

We use the following config as baseline :

1"feedforward": {
2  "hidden_sizes": [64, 32, 16, 8],
3  "lookback": 20,
4  "epochs": 100,
5  "learning_rate": 0.001,
6  "batch_size": 32
7},

Realtime Monitor and Raw Results

Case 2b. Using transformers

We use the following config as baseline :

1"transformer": {
2  "d_model": 64,
3  "nhead": 4,
4  "num_layers": 2,
5  "sequence_length": 10,
6  "epochs": 100,
7  "learning_rate": 0.001,
8  "batch_size": 32
9}

Realtime Monitor and Raw Results

Case 2c. Using classical ML algorithms like Random Forest

We use the following config as baseline :

1"classical": {
2  "algorithm": "random_forest",
3  "n_estimators": 100,
4  "max_depth": null,
5  "lookback": 20
6}

Realtime Monitor and Raw Results

Case 3: With more training data

Training load is now for 5 minutes. Evaluation load remains the same :

1# Training load (increased to 5 mins)
2locust -f locustfile.py --headless -u 100 -r 10 --run-time 5m
3
4# Evaluation load (same as before)
5locust -f locustfile.py --headless -u 100 -r 10 --run-time 5m

Case 3a. Using normal feed-forward networks

We use the same baseline as before :

1"feedforward": {
2  "hidden_sizes": [64, 32, 16, 8],
3  "lookback": 20,
4  "epochs": 100,
5  "learning_rate": 0.001,
6  "batch_size": 32
7},

Realtime Monitor and Raw Results

Case 3b. Using transformers

We use the same baseline as before :

1"transformer": {
2  "d_model": 64,
3  "nhead": 4,
4  "num_layers": 2,
5  "sequence_length": 10,
6  "epochs": 100,
7  "learning_rate": 0.001,
8  "batch_size": 32
9}

Realtime Monitor and Raw Results

Case 3c. Using classical ML algorithms like Random Forest

Yeahhh, again, same baseline as before :

1"classical": {
2  "algorithm": "random_forest",
3  "n_estimators": 100,
4  "max_depth": null,
5  "lookback": 20
6}

Realtime Monitor and Raw Results

Case 3d. [Bonus] Using updated LSTM

1"lstm": {
2  "input_size": 10,
3  "hidden_size": 64,
4  "num_layers": 10,               // increased this from 2
5  "sequence_length": 100,         // increased this from 10
6  "epochs": 100,
7  "learning_rate": 0.001,
8  "batch_size": 32
9},

Realtime Monitor and Raw Results

Conclusion

NeuroGC demonstrates that Python’s garbage collector can get a little smarter by learning from application and process-level metrics. Across all experiments, deeper LSTMs with more training clearly shine, delivering the most noticeable gains. While I had expected Transformers and classical algorithms to dominate, the LSTMs ended up taking the crown.

Overall, I’d call this experiment a modest success. Next, it might be interesting to explore CPython and see whether training a model at the C level could bring even greater benefits.

That said, Python already does an impressive job with GC using reference counting. In languages like Java, where garbage collection can be a bigger bottleneck, approaches like this could potentially have a more significant impact.