For Cycle 13

[ghubstan]

Summary

Specify the total amount of BSQ you are requesting:

BSQ requested: 6,675 USD / 0.63 = 10,595 BSQ

Based on Cycle 13 BSQ rate for Cycle 13 is 0.63 USD per 1 BSQ

Contributions delivered

• Investigated issue 3918 and found sources of unnecessarily large resident memory use by JVM and Linux glibc. @freimair implmented first finding of that investigation which reduces the JVM's MAXRam setting from 128 GB to 4 GB in PR 4048, and the change reduced resident memory use on a clean Bisq installation on Ubuntu18 from ~ 4.8GB to ~1.7 GB. Other tested ways of reducing resident memory usage by ~ 500MB are described in 3918 (if needed in the future). Also added troubleshooting tips under the heading Bisq is using too much RAM on the bisq wiki.
  This small setting change was the result of a month of profiling, analyzing and testing, using several profiling technologies including Java Mission Control / Java Flight Recorder, JProfiler, async-profiler, bcc and bpftrace tools, and comparing memory use of NVIDIA GPU and Mesa drivers -- all with the assumption Bisq and JFX are leaking memory. There are leaks yet to be found and fixed in Bisq and JFX, but the only firm conclusion my analysis supported was that Bisq's JVM was reserving far more resident and virtual memory at startup than the Linux JVM needs. I did not find problems with Bisq's on-heap memory management.
  Requesting 4,762 BSQ = 3,000 USD

• Improve AvoidStandyModeService -- PR 4060
  This change reduced disk reads by ~ 50% according to @freimair , and about 1 GB of resident memory allocation per hour according to my testing and profiling on Linux. This was accomplished by running native suspend/sleep inhibitors on Linux and OXS (but not Windows), instead of playing the silent audio file.
  Requesting 1,111 BSQ = 700 USD

• Reduce Dependency Conflicts -- Issue 4086
  PRs 4089, 4108 have been merged to eliminate dependency conflicts among grpc, gson, apache commons, apache httpclient/core, logback, and slf4j libraries.
  Requesting 556 BSQ = 350 USD

• Began gRPC daemon and cli development based on existing POC. The first contribution (PR 4096) pulled protobuf definitions files out the :common and :core subprojects into a new :proto subproject. This eliminated :cli's direct dependency on :core, and transitive dependencies within :common. It also reduces :common and :core incremental build times. The second merged PR 4097 hid netty debug stacktraces in the :cli, and introduced other changes to tidy up cli in preparation for the next phase of development: implementing rpc authentication and wallet protection methods (in progress).
  Requesting 1,905 BSQ = 1,200 USD

• Delivered password based gRPC authentication and test suite. Prior to this contribution, studied gRPC's authentication mechanism and implemented a POC for macaroon based authentication over TLS (PR 4129). Macaroon + TLS authentication was determined to be too much overhead for both the primarily localhost based daemon+cli, and end users, so a simpler password based auth implementation was merged from PR 4189.
  Requesting 1,905 BSQ = 1,200 USD

• Helped test release v1.3.2. Fixed issue #4158 in PR 4161. The bug was causing a test failure, blocking full gradle builds. Also tested Funds Managenemt, Wallet Managment, and Application Setttings
  Requesting 357 BSQ = 225 USD

Contributions in progress

gRPC daemon and cli development

• Migrate cli test suites to bats testing system: PR 4209

• Add gRPC wallet protection endpoints: PR 4214

• Add gRPC wallet protection endpoint test cases: PR 4243

Roles performed

Provide links to your monthly report on any roles you are responsible for.

[cbeams]

@ghubstan, I've looked through everything so far, and it all looks reasonable to me (thanks for the great work, btw!). The only item that raised a yellow flag for me is 3K usd for the memory usage improvements. I didn't track this work while it was going on, and I can easily imagine that it required a lot of time and effort to analyze, test, etc, but this wasn't mentioned in your description above. I imagine others might wonder about this item too, so perhaps you could explain a bit what merited the larger amount. Thanks.

Also, I know that your Cycle 12 request was never submitted due to timing issues, and that the content above is basically a copy and paste from that request. I'm wondering, though, why you didn't mark this (Cycle 13) request as [WIP] per https://bisq.wiki/Compensation#Create_your_compensation_request_issue. The reason for doing this is that you may want to add more items to this request before the compensation request deadline for Cycle 13 hits.

[ghubstan]

@cbeams , Thanks for reviewing this. I did plan to include the rpc work that has been merged in Contributions in progress section above. I just haven't got around to it. (According to the calendar, I have until end of Saturday, May 9 to get that done.)

I will also add more explanation for my 3K request for improving the memory issue before end of May 9. It did require a lot of time and effort to profile, analyze, test, etc., but I didn't mention that because I have heard you say (in docs and you-tube) that comp is based on works' value to the user, not how much time spent doing the work. I am glad you encouraged me to explain.

[ghubstan]

This request is ready for review

[sqrrm]

As stand in team lead I approve this request. Please submit your DAO proposal and paste the transaction ID here as a comment when complete, thanks.

I think it's not always clear why a certain PR or contribution is worth more than others. It helps more people understand the work that goes into a piece of code when you explain it like you did now for the memory usage profiling. It's also not easy to value the memory usage improvements so using a reasonable amount of work to accomplish the task as a basis for valuation is often the only way.

[ghubstan]

ProposalTxId = 45e792c8432b3217cb21ad9482eecfcc3b27b7c052fa81e875698637b3fb551b

[MwithM]

was:accepted