Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug level #1

Closed
julianofischer opened this issue Oct 27, 2015 · 4 comments
Closed

Debug level #1

julianofischer opened this issue Oct 27, 2015 · 4 comments

Comments

@julianofischer
Copy link
Contributor

Suggestion:

When running MaxPropRouter, there is a snippet of code frequently called (from routing.maxprop.MeetingProbability, which prints some information in output stream.

if (probs.size() >= maxSetSize) {
            core.Debug.p("Probsize: " + probs.size() + " dropping " +
                    probs.remove(smallestEntry.getKey()));

        }
}

It is frequently annoying and could lead to performance degradation.
Perhaps the best default option for debugging is not debugging, actually.

Actually, in my code I changed the snippet in order to workaround:

if (probs.size() >= maxSetSize) {
            probs.remove(smallestEntry.getKey()));
            //core.Debug.p("Probsize: " + probs.size() + " dropping " +
           //         probs.remove(smallestEntry.getKey()));

        }
}

It would be nice a (not hardcoded) way to disable it (increase the debug level).
I could contribute with a pull request if the authors agree to reade the debug level from settings:

    Debug.level = x
@tk721
Copy link
Collaborator

tk721 commented Oct 28, 2015

One, somewhat orthogonal thing would be to guard the debug logging statements with a global static final DEBUG_BUILD if-statement. For production, compiling with DEBUG_BUILD = false would cause the debug logging statements to be stripped out.

@julianofischer
Copy link
Contributor Author

I believe @tk721's idea will lead to a better performance since the "undesired" code will be removed from bytecode due to compiler optimization. Since performance matters, I think it is better choice than the one I myself suggested, so +1 for Teemu's suggestion.

@barun-saha
Copy link

This would be a nice feature. In addition to what @julianofischer and @tk721 have already mentioned, perhaps we can have different levels of information emission, such as INFO, DEBUG, and ERROR, which are commonly used by many software. However, an important consideration would be the volume of information that the simulator emit as a whole.

@akeranen
Copy link
Owner

+1 for @tk721's idea. There is already support for different debug levels at the core/Debug.java, but apparently I forgot to define the constants for them. Should fix it.

@tk721 tk721 mentioned this issue Nov 12, 2015
@tk721 tk721 closed this as completed Nov 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants