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

TIL #11

Open
yihong0618 opened this issue Jan 31, 2023 · 3 comments
Open

TIL #11

yihong0618 opened this issue Jan 31, 2023 · 3 comments
Labels

Comments

@yihong0618
Copy link
Owner

yihong0618 commented Jan 31, 2023

#TIL

til add ?

整合成一张 MD?

@yihong0618 yihong0618 added the TIL label Jan 31, 2023
@yihong0618
Copy link
Owner Author

git

同步其它项目

git remote add abc
git remote update
git merge abc/branch_a

@yihong0618
Copy link
Owner Author

postgres

Why does the OID jump by 3 when creating tables?

When you create a table, it also creates two data types: tablename and
_tablename. For example, for your table t1, you should have a t1 type and a
_t1 type. Both have OIDs. On my cluster, your example gives me:

Why does my first tablespace in PostgreSQL always get the OID 16384?

123 *              OIDs beginning at 16384 are assigned from the OID generator*              during normal multiuser operation.  (We force the generator up to*              16384 as soon as we are in normal operation.)

@yihong0618
Copy link
Owner Author

Rust

why tokei is amazing fast

Well a lot of the performance came from replacing slice.iter().any(|i| line.starts_with(i)) with aho_corasick::AhoCorasick in a hot loop, as well adding per language memoization for things like AhoCorasick. I also added a heuristic where Tokei essentially splits your file from the start until there's "important" syntax that needs to be tracked across lines, and divides that work into two separate parallel tasks. This means if your file has simple enough syntax it can be counted entirely in parallel.

It's hard to list all or tell which made the most impact on performance, as I essentially tried to make every piece that could be concurrent, concurrent, and then repeatedly benchmarked to see if it actually improved it.

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

No branches or pull requests

1 participant