Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grep max-count option #77

Closed
tolot27 opened this issue May 9, 2019 · 5 comments
Closed

grep max-count option #77

tolot27 opened this issue May 9, 2019 · 5 comments

Comments

@tolot27
Copy link

tolot27 commented May 9, 2019

It would be nice if csvtk grep would support a -m NUM, --max-count=NUM parameter like the usual grep utility. The rational behind this is performance improvements.

I'm repeatedly looking for unique values (stored in a file) in a column of a very large database containing only unique values (primary keys). It takes some time to go over the hole database and I believe if I could provide something like --max-count=1 it would ran faster. But that requires a a map for the querying values to there occurences already found.

Here is the command I use: pigz -dc prot.accession2taxid.gz | csvtk grep -t -f accession.version -P some_accessions.txt | csvtk cut -t -f accession.version,taxid

prot.accession2taxid.gz is several gigabases large.

@shenwei356
Copy link
Owner

I thought it has a flag like seqkit grep, but it doesn't.

      --delete-matched        delete matched pattern to speedup

It would gain some speed improvement, without using extra data structure.

@tolot27
Copy link
Author

tolot27 commented May 10, 2019

Yeah that would cover the most frequent (IMHO) use case of --max-count=1. But it should work for "normal" and regex patterns. In seqkit grep it looks like it is only used for regex patterns.

@shenwei356
Copy link
Owner

I'll add this weekend

@shenwei356
Copy link
Owner

shenwei356 commented May 12, 2019

It works for "normal" and regex patterns now:

@tolot27
Copy link
Author

tolot27 commented May 13, 2019

Many thanks. I got a slight runtime improvement. Not much because all hits were near the end of the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants