On Tue, 22 Jun 2021 14:05:25 +0300 Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > I was thinking the same, but could not find a use case. That means to > give control to the user to decide what parts should be compressed. > This will complicate the implementation, new trace-cmd parameters > should be added. As I couldn't thought of a use case, decided to go > with the simpler approach. May be it makes sense only for the trace > data, but the metadata should be always compressed if possible. I haven't though too hard for a use case, but the problem about going with the simple approach is that if we come up with a use case, we can never implement it. I like to error on the side of flexibility at the cost of some complexity at the beginning. You may not need that flexibility for years to come, but when it happens, you'll be really glad you did it that way. When going with the simple approach, and putting yourself in a corner, you are setting yourself up for easy work now, but could potentially have a real hard time, including complete rewrites, or just giving up on features, in the future. The use case I had was not to allow users to have a lot of options, but it lets us know if we want to bother compressing everything or not. We can perhaps find that compression takes up more time, and doesn't save us anything. If we find that's the case, we can chose not to compress later. By adding a flag that tells trace-cmd if a section is compressed or not, we don't need to worry about that change. We could uncompress a section, and everything will still "just work"! -- Steve
|