drogonframework / drogonframework/drogon
Potential for performance improvements.
- Dominant language
- C++
- Stars
- 14.3k
- Forks
- 1.4k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 15
Description
Hello. I've just started using Drogon now, and I noticed first off as soon as I access:
drogon::HttpRequestPtr req;
req->getHeader();
That there are interesting performance implications in calling getHeader. Ordinarily I wouldn't mind, but I bring this up because I thought Drogon was supposed to be super-focused on performance and setting benchmark records.
I've noticed that:
1) It takes std::string (could it take std::string_view)?
2) Every value for each key is stored in a std::string (could it be have a const view to the original headers/request? I noticed Glaze's json library does something clever of this sort)
3) Every access of a header is done with a string (could it be done with enum)?
4) It's virtual (Does it have to be)?
I've noticed other interesting design decisions, such as every "newHttpJsonResponse" heap allocating and constructing atomically referenced shared_ptrs.
Obviously being new to this project I don't really know anything about it's design, so I'm just asking out of curiosity how realistic it would be to improve the API for performance's sake?
Contributor guide
Research direction
Start by reviewing the HttpRequest::getHeader API and the newHttpJsonResponse construction path mentioned in the issue. Benchmark the current behavior before deciding whether the proposed string, storage, enum, virtual-dispatch, and allocation changes are realistic; the issue does not define a specific implementation or completion test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100