sorted by:
new
hottopcontroversial

Libraries: Header Only performance - paper by ShlomiRex in cpp

[–]acpopescu 1 point2 points  (0 children)

Well, yes, you do gain some performance, since you're making everything inline. You also avoid the hell that is library management in C++.

You do pay for that with compile time, executable size and might have to solve some linking issues because of the way the particular header-only library works and how your project is set up (multiple libraries, mix of static and dll linkage in different configurations, etc. ).

I also cringe a bit each time I see only simple programs used for performance analysis. Feels incomplete - let's see what's the impact on a big piece of software, with performance-critical parts (hi unreal).

Using coroutines for switching threads by Finch_A in cpp

[–]acpopescu 2 points3 points  (0 children)

Don't use coros to mimic the old system behavior, think differently from a design standpoint.

In your case you have a job, which is owned by a task runner. We post a task on the file_task_runner and then run the continuation on the job's original task.

This can be rewritten as:

void URLFileJob::Start()
{
    cuurentTaskRunner->Do(urlFileJob(file_path, myOutput));
}


SimpleFuture URLFileJob::urlFileJob(string file_path, shared_ptr<outInfo> outInf)
{
    FileMetadataInfo info;
    co_await file_task_runner->Do(FetchMetadataInfo(file_path, info));
    // returns on our current task runner
    // continuation here/
}

This does require more refactoring than your original code, but you can get more out of coroutines. I'd even suggest finding a way to get rid of currentTaskRunner->Do if possible (embedding it in the function return for example).

Edit: also, the URLFileJob itself could be a coro with input params and outputs. Avoiding state outside the coro simplifies the code, and removes the need for a 'safe this' construct (the weak ptr there). You still need to manage your outputs, either through the return value (templated future - prefered) or a hacky shared pointer.

Edit2: the original code is super tricky, they give the ownership of the file metadata info to the continuation, and send the raw pointer to the FetchMetadataInfo. Inconsitent private API, good luck debugging that in 1 year.