mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benno Evers <bev...@mesosphere.com>
Subject Re: Review Request 63368: Added MemoryProfiler class to Libprocess.
Date Mon, 12 Feb 2018 14:16:56 GMT


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 197-240 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line197>
> >
> >     I would still merge these two functions. Since it is for internal use only,
it is fine to expect the user to understand when to expect a previous value (looks like there
is one such instance in the current code).
> >     
> >     How about this?
> >     ```
> >     template<typename T>
> >     Result<T> writeJemallocSetting(const char* name, const T& value, bool
requestPrevious)
> >     {
> >       if (!detectJemalloc()) {
> >         return Error(JEMALLOC_NOT_DETECTED_MESSAGE);
> >       }
> >     
> >       T previous;
> >       T* pprevious = requestPrevious ? &previous : nullptr;
> >       size_t size = sizeof(previous);
> >       size_t* pszie = requestPrevious ? &size : nullptr;
> >       
> >       int error = mallctl(
> >           name, pprevious, psize, const_cast<T*>(&value), sizeof(value));
> >     
> >       if (error) {
> >         return Error(strings::format(
> >             "Couldn't write value %s for option %s: %s",
> >             value, name, ::strerror(error)).get());
> >       }
> >     
> >       return requestPrevious ? previous : None();
> >     }
> >     ```
> >     
> >     And if you make `value` optional, you can have a single function plus maybe
three syntactic sugar functions with descriptive names that call into the basic one.

To be honest this looks quite overloaded to me. If you insist I will change it, but I think
two simple functions are better than one complicted.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 264 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line264>
> >
> >     Say "using std::string" in the beginning of the file and save hundreds of characters!
> 
> Benno Evers wrote:
>     I'm not a fan of using `using`-directives just to save some typing, as it puts a
large cognitive burden on the reader: Is `string` referring to name imported to the global
namespace via `using`, a class-local or a function-local typedef, maybe defined in some `stout`-header?
In any case, one has to jump to a different context to double-check. Using `std::string`,
on the other hand, is not ambigous.
> 
> Alexander Rukletsov wrote:
>     ```
>     alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "std::string" ./src | wc
-l      
>          465
>     
>     alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "using std::string" ./src
| wc -l
>          371
>     ```
>     We have ~370 .cpp files with `using std::string` and \<100 mentions of `std::string`.
We also do not provide our own string type; ambiguous local typedefs shall not be used.
>     
>     In addition to the above, I personally find meaningless prefixes and characters,
like `std::`, contributing to the cognitive load of the code.

> We also do not provide our own string type; ambiguous local typedefs shall not be used.

You may know this, but I don't think you can assume every reader of the code does. Also, the
second rule may be followed `de-facto`, but I don't think it's written down anywhere.


- Benno


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/63368/#review196894
-----------------------------------------------------------


On Feb. 6, 2018, 5:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63368/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2018, 5:45 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This class exposes profiling functionality of jemalloc memory allocator
> when it is detected to be the memory allocator of the current process.
> 
> In particular, it gives developers an easy method to collect and
> access heap profiles which report which pieces of code were
> responsible for allocating memory.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am 3071b7ce2b82a4ce0ea62e4d2b3518a6f5114803 
>   3rdparty/libprocess/include/process/memory_profiler.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/process.hpp 8661706cb058efb26f5bfbcc84972f9930d3670f

>   3rdparty/libprocess/src/CMakeLists.txt f002c157dc2ca64da66bc4e61f5095f2b533ae1f 
>   3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION 
>   3rdparty/libprocess/src/process.cpp 42e7adf740b234ebf23d2dcb71440749c0ed87ec 
> 
> 
> Diff: https://reviews.apache.org/r/63368/diff/5/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message