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

exclude CreatePidFile() function on WIN32 as it is unused #2855

Merged
merged 1 commit into from
Aug 5, 2013
Merged

exclude CreatePidFile() function on WIN32 as it is unused #2855

merged 1 commit into from
Aug 5, 2013

Conversation

Diapolo
Copy link

@Diapolo Diapolo commented Jul 24, 2013

No description provided.

@BitcoinPullTester
Copy link

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a034c7ebb6995c342fea289d04a6198d793eab08 for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

@Diapolo
Copy link
Author

Diapolo commented Jul 24, 2013

This should fix problems some people with mingw-64 compilers have.

In file included from alert.h:13:0,
                 from alert.cpp:11:
util.h:211:57: error: 'pid_t' has not been declared
 void CreatePidFile(const boost::filesystem::path &path, pid_t pid);

I know error and fix seem not to match, but as we don't ever user CreatePidFile() on Windows it seems cleaner to avoid compilation of that function as to define pid_t for Windows.

@sipa
Copy link
Member

sipa commented Jul 24, 2013

ACK

gavinandresen added a commit that referenced this pull request Aug 5, 2013
exclude CreatePidFile() function on WIN32 as it is unused
@gavinandresen gavinandresen merged commit e622f3f into bitcoin:master Aug 5, 2013
IntegralTeam pushed a commit to IntegralTeam/bitcoin that referenced this pull request Jun 4, 2019
* Merge bitcoin#13176: Improve CRollingBloomFilter performance: replace modulus with FastMod

9aac9f9 replace modulus with FastMod (Martin Ankerl)

Pull request description:

  Not sure if this is optimization is necessary, but anyway I have some spare time so here it is. This replaces the slow modulo operation with a much faster 64bit multiplication & shift. This works when the hash is uniformly distributed between 0 and 2^32-1. This speeds up the benchmark by a factor of about 1.3:

  ```
  RollingBloom, 5, 1500000, 3.73733, 4.97569e-07, 4.99002e-07, 4.98372e-07 # before
  RollingBloom, 5, 1500000, 2.86842, 3.81630e-07, 3.83730e-07, 3.82473e-07 # FastMod
  ```

  Be aware that this changes the internal data of the filter, so this should probably
  not be used for CBloomFilter because of interoperability problems.

Tree-SHA512: 04104f3fb09f56c9d14458a6aad919aeb0a5af944e8ee6a31f00e93c753e22004648c1cd65bf36752b6addec528d19fb665c27b955ce1666a85a928e17afa47a

* Use unordered_map in CSporkManager

In one of my profiling sessions with many InstantSend transactions
happening, calls into CSporkManager added up to about 1% of total CPU time.
This is easily avoidable by using unordered maps.

* Use std::unordered_map instead of std::map in limitedmap

* Use unordered_set for CNode::setAskFor

* Add serialization support for unordered maps and sets

* Use unordered_map for mapArgs and mapMultiArgs

* Let limitedmap prune in batches and use unordered_multimap

Due to the batched pruning, there is no need to maintain an ordered map
of values anymore. Only when nPruneAfterSize, there is a need to create
a temporary ordered vector of values to figure out what can be removed.

* Instead of using a multimap for mapAskFor, use a vector which we sort on demand

CNode::AskFor will now push entries into an initially unordered vector
instead of an ordered multimap. Only when we later want to use vecAskFor in
SendMessages, we sort the vector.

The vector will actually be mostly sorted in most cases as insertion order
usually mimics the desired ordering. Only the last few entries might need
some shuffling around. Doing the sort on-demand should be less wasteful
then trying to maintain correct order all the time.

* Fix compilation of tests

* Fix limitedmap tests

* Rename limitedmap to unordered_limitedmap to ensure backports conflict

This ensures that future backports that depends on limitedmap's ordering
conflict so that we are made aware of needed action.

* Fix compilation error on Travis
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants