Open PavelAndrianov opened 5 years ago
Yes, truncating source files with help of some optional function may help to reduce size of standalone error traces as well as coverage sources (issue #40).
The #40 is a bit different. There the main idea is to load the whole source file by fragments. And I speak about storing only necessary fragments, without reloading them. So, many source fragments will be totally unavailable in offline mode.
But still similar idea can be used for displaying sources of error traces in CV (not standalone mode), which also may require a lot of time. Maybe, some ideas also will be useful for coverage.
Maybe, yes, but usually I need the whole sources while analysing an error trace in CV mode. So, we will need to upload fragments in most cases. However, it might helps.
This issue is important to present standalone error traces.
@PavelAndrianov Is this issue still actual?
I think, yes. I did not use standalone error traces recently, but in recent os kernel launches, there are quite huge files ( about 100 kLoc), which have problems with displaying.
The stand-alone error traces are still very heavy. The trace itself is about 70 mb and an archive is 6 mb. It is quite big for attaching the archives to letters or issues. An idea is to reduce a number of sources, which are related to the trace. For example exclude auxiliary ones, like main, as it says nothing to developers. A more intelligent idea is to include only parts of real source files: just a function, which is necessary for the error trace. Moreover, such optimization will also help with slow opening of the .html file.