FLEXI-STREAMS:OCTETS-TO-STRING in HANDLE-FRAME taking 20%
erjoalgo opened this issue · comments
I noticed that the FLEXI-STREAMS:OCTETS-TO-STRING by HUNCHENSOCKET::HANDLE-FRAME is taking up about 20% of my service when under stress:
302 19.6 HUNCHENSOCKET::HANDLE-FRAME [54]
1 0.1 302 19.6 FLEXI-STREAMS:OCTETS-TO-STRING [153]
Is there a suggestion to optimize this?
@erjoalgo, I'm very very close to banning you from this issue tracker. You can't make the hunchentoot issue tracker a chat about every issue of your project. It has to be about problems or suggestions direcly related to hunchensocket. How can I possibly know what your service does. If it does very little for example, it's possible that most of the time is converting octets.
See what I wrote in the other issues. Send me an email instead. Or ask in IRC #lisp.
You closed 4 of the issues I reported stating that "the huchensocket issue tracker is not a chat room". In each of those issues, I've described the problem, when it happens, and provided a full stack trace pointing to hunchensockets internal code. I don't see where you got the sense that I am treating the issue tracker as a chat room.
In this case, the sbcl profiler appeared to show that FLEXI-STREAMS:OCTETS-TO-STRING was being called internally in the hunchensockets code, and this is why I asked here whether could be optimized. I didn't think it was relevant to know what my service does in order to possibly answer this, but I could be wrong.
I was trying to contribute to this good project, which I have used, by reporting possible issues I encountered while using it, in hopes of helping future users avoid them and improve the project. But if your attitude is that your project is already perfect and that reporting possible issues is a personal attack against you, then, definitely please ban me from the tracker, as you have threatened.
@erjoalgo you open four issues back to back then wait a month before replying. You're right it's not a chat room at all, I just don't know what to call it. It's not a good way to report bugs, I can tell you that.
I didn't think it was relevant to know what my service does in order to possibly answer this, but I could be wrong.
In any program some things are going to take some time. In hello-world.c, printf probably takes near 100% of time, are you going to submit a bug report to libc about printf?
I opened four issues, and you waited less than a day before closing them all because you somehow took them as personal attacks. Meanwhile, most normal projects appreciate receiving bug reports, which at worst are invalid reports, but which could help them improve.
FYI, in general you can't expect users of your library to know exactly what is causing an issue, or to be able to read your mind about what exact information you expect to be contained in reports. BTW some projects use a template to suggest filling in required information when reporting an issue, which yours doesn't.
I got several exceptions with backtraces originating in hunchensockets while using it, and I provided as much information as I thought was relevant, including the full backtrace and what appeared to be triggering them. If you thought more information was needed, you could have simply requested it and I would have been happy to provide it. Or if thought the behavior was expected, or if there is a user-error that could have caused those problems, you could have easily indicated that as well. This is a normal part of bug reporting -- not all bugs reported by users are valid, or have all the information a maintainer thinks he might need upfront.
But you didn't indicate any of that or request additional information, you simply closed them right away. This is why I waited a month to reply -- you made it clear with your defensive attitude and threats that trying to track down these issues was going to be a confrontation and an uphill battle, and I wasn't interested in that.
I guess coming from hunchentoot, I was used to the behavior of conditions being trapped by default (which is the case unless hunchentoot:*catch-errors-p* is nil), and the fact that conditions kept popping up in Slime during what seemed like normal client use felt like a possible bug.
My suspicion about those backtraces was that they were caused by abruptly closing a tab in the browser where a javascript WS client was actively connected to a hunchensockets server, which killed the client before giving it a chance to properly close the connection, resulting in connection timeouts that popped up as conditions or low-level socket errors. I felt at the time it was a bug since I expected an end user to be able to close a browser tab at any time, but I understand that from the library perspective, you probably don't want to make assumptions about e.g. the client being in a browser tab. I probably could have simply trapped those errors myself from my client code.
I'm sorry I didn't include more information in the original reports, it was late at night and I just wanted to log the issue somewhere before going to bed and possibly fill in more information the next day, so I probably didn't put as much effort as I could have.
Anyway, thanks for clearing this up and for your contribution to the project.
Replying to this in #20, where it belongs.