[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu-devel
Subject:    D29440: Move 2 logging statements from debug to info. printed only once per focus session.
From:       Doug Summers <noreply () phabricator ! kde ! org>
Date:       2020-05-05 18:08:22
Message-ID: a864697e734561e60f4ca4593d677158 () localhost ! localdomain
[Download RAW message or body]

[Attachment #2 (text/plain)]

dmsummers added a comment.


  Absolutely!    Developers debug until their algorithms actually work.    Users are \
not developers.   They presume algorithms work and just monitor/analyze performance \
for tuning purposes.    These use cases are very fundamentally different.    No user \
wants to wade through tons of debug to get summary data they need for performance \
analysis.   Another analysis example illustrates the point.    I use PHD2 not because \
I don't like the internal guider, but because there's a post analysis tool \
(logViewer) that can show how guiding performed (and whether I need to tune or not).  \
That's not debugging.    The first rule of performance assessment/improvement is \
measurement.   Without the summary measurements, it's hard to improve.   I suggest \
the vision for INFO level should be to support performance assessment and aid users \
in tuning/improvement.    Cheers,  Doug

REPOSITORY
  R321 KStars

REVISION DETAIL
  https://phabricator.kde.org/D29440

To: murveit
Cc: mutlaqja, dmsummers, kde-edu, narvaez, apol


[Attachment #3 (text/html)]

<table><tr><td style="">dmsummers added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: \
right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: \
#F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: \
inline-block; border: 1px solid rgba(71,87,120,.2);" \
href="https://phabricator.kde.org/D29440">View Revision</a></tr></table><br \
/><div><div><p>Absolutely!    Developers debug until their algorithms actually work.  \
Users are not developers.   They presume algorithms work and just monitor/analyze \
performance for tuning purposes.    These use cases are very fundamentally different. \
No user wants to wade through tons of debug to get summary data they need for \
performance analysis.   Another analysis example illustrates the point.    I use PHD2 \
not because I don&#039;t like the internal guider, but because there&#039;s a post \
analysis tool (logViewer) that can show how guiding performed (and whether I need to \
tune or not).   That&#039;s not debugging.    The first rule of performance \
assessment/improvement is measurement.   Without the summary measurements, it&#039;s \
hard to improve.   I suggest the vision for INFO level should be to support \
performance assessment and aid users in tuning/improvement.    Cheers,  \
Doug</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R321 \
KStars</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a \
href="https://phabricator.kde.org/D29440">https://phabricator.kde.org/D29440</a></div></div><br \
/><div><strong>To: </strong>murveit<br /><strong>Cc: </strong>mutlaqja, dmsummers, \
kde-edu, narvaez, apol<br /></div>



[prev in list] [next in list] [prev in thread] [next in thread]