# Optimizing \`qiime feature-classifier classify-sklearn\`

**URL:** https://forum.qiime2.org/t/optimizing-qiime-feature-classifier-classify-sklearn/2025
**Category:** User Support
**Tags:** feature-classifier
**Created:** [November 30, 2017, 3:49pm UTC](https://forum.qiime2.org/t/optimizing-qiime-feature-classifier-classify-sklearn/2025 "2017-11-30T15:49:08Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![Nicholas\_Bokulich](https://forum.qiime2.org/user_avatar/forum.qiime2.org/nicholas_bokulich/32/19937_2.png) [@Nicholas\_Bokulich](https://forum.qiime2.org/u/Nicholas_Bokulich)
#### Post date: [November 30, 2017, 5:24pm UTC](https://forum.qiime2.org/t/optimizing-qiime-feature-classifier-classify-sklearn/2025/3 "2017-11-30T17:24:56Z")

</div>

Hi @nick-youngblut,

Thanks for posting! Sorry to hear that the classifier has been giving you some grief. It sounds like you have a large number of query sequences — are these OTUs or sequence variants? What reference database are you using? Out of curiosity, what type of samples are you analyzing?

> [@nick-youngblut](#):
>
> Given the high reads-per-batch, it seems that multi-threading (–p-n-jobs) won’t actually be used unless --p-reads-per-batch is reduced to something reasonable (eg., 1000 reads per batch).

This is what is proposed in [this forum post](https://forum.qiime2.org/t/using-the-silva-pre-trained-classifier-consumes-more-than-256-gb-of-memory/1199/19) to achieve meaningful parallelism.

> [@nick-youngblut](#):
>
> why is the default --p-reads-per-batch so high?

@BenKaehler may have some insight into the rationale behind this setting.

> [@nick-youngblut](#):
>
> why does qiime feature-classifier classify-sklearn take so long, even when using many threads?

**Short answer:** 40k is a very large number of features and will take a long time to run with any method.

**Long answer:** it is true, the naive bayes classifier implemented by RDP is faster (though the gap narrows as more reference sequences are added) because it is written in Java. We have worked to [optimize accuracy](https://peerj.com/preprints/3208/) over speed, because we find that methods like dada2/deblur tend to greatly reduce feature counts by weeding out spurious observations, and thus downstream runtime steps (including sequence classification) are greatly reduced, to the extent that parallelization isn't even necessary. Query sequences are only likely to run into the tens of thousands with 1) very large studies or 2) OTU picking without aggressive quality control, so classification runtime hasn't been so much of an issue for most users.

Is your concern that parallelization is not reducing runtime to the expected degree?

---

_[View the full topic](https://forum.qiime2.org/t/optimizing-qiime-feature-classifier-classify-sklearn/2025)._