These are a subset of my bitcoin-4diff patches have been well-tested against the latest release version.
Cache the RPC user and password in strRPCUser/strRPCPass so that they don't need to be extracted on each RPC call.
Fix a memory leak in the pthreads version of CreateThread.
the latest release version.
Cache the RPC user and password in strRPCUser/strRPCPass so that they don't
need to be extracted on each RPC call.
Fix a memory leak in the pthreads version of CreateThread.
Why is the user/pass cached? map access is very, very fast, so it seems unlikely that it would ever show up on a profile?
Was this just a guess, or do you have any data showing a positive impact from that change?
All of my micro-optimizations are a result of benchmarking. The map access is fast in the sense that it scales well even if there are a large number of entries in the map. It is, however, slow if the map is very small. (In fairness, my benchmark was hitting the client with massive numbers of RPC requests.)
Latest patches add much faster HexStr and faster Base64 decode. These changes were made based on profiling. Again, the profiled workload was large numbers of RPC requests, primarily 'getwork'. So they primarily benefit controllers for pooled mining. (See the Bitcoin forums, several large pools are using these patches.)
While people who do large numbers of 'getwork' requests are certainly minority users of the code in terms of number of installations, they have a disproportionate affect on things like which transactions wind up in the public hash chain. They will need optimizations to the RPC/JSON/getwork paths. The issue is whether those optimizations will be maintained as a fork or merged into the mainline. That's really a code policy issue that transcends the issue of these specific patches.
Code review issue: these commits must be redone with a useful commit message.
The first line of any git commit must be a one-line summary of logical code change. Further lines, if any, elaborate and describe the change in detail.
Any user using "git shortlog" will receive an incomprehensible summary: "These are a subset of my bitcoin-4diff patches have been well-tested against" That tells the user absolutely nothing about the change.
Neither does "Additional optimization from 4diff." tell us anything about -what- is the optimization, and -where- in the code it occurred.
Ahh, okay. I haven't used github before. In the systems I am used to, it is the code that is pulled.