2009/7/28 Robert Bradshaw <rober...@math.washington.edu>:
>
> On Jul 27, 2009, at 5:22 PM, David Kirkby wrote:
>
>>
>> I noticed that several packages build Sage with the -g option to ,
>> which adds debugging information. This has 3 downsides
>>
>> 1) The binaries are slower
>> 2) The binaries are bigger
>> 3) Possibly takes longer to compile - I've not verified this, but I
>> suspect it does.
>
> Just a sec, is there any empirical evidence for the above? (1) seems
> like the most severe, but as far as I understand, there is no speed
> impact on the resulting binaries (it just generates symbol tables).
> (2) seems like the biggest issue, but is is a 10% increase? Double
> the size? More? Sage is big, but HD space is relatively cheap. As for
> (3), it the only ones who care about this are those who compile from
> source, and those are the ones more likely to want the debug symbols.
> Again, some some hard numbers would be good.
>
> I've found cases where it's very useful to be able to fire up gdb and
> see where something's going on, often I don't now ahead of time where
> I'm going to be looking for a segfault. Debugging symbols are
> especially useful because it's open source, so one can actually see
> the code in question (even if one has no intent on modifying it). I
> think any step backwards in developer friendliness should be taken
> with caution.
>
>> I think it would be a good idea to remove the -g flag in general. As
>> far as I am aware, there is the SAGE_DEBUG variable, which should be
>> set to 1 for debugging. I'm doing this from memory, not testing it as
>> I write, but
>>
>> #!/bin/bash
>> debug="${SAGE_DEBUG-0}"
>>
>> if [ x$debug = "x1" ] ; then
>> CFLAGS="$CFLAGS -g"
>> fi
>> should add -g only when the environment variable SAGE_DEBUG is set
>> to 1.
>
> As an alternative, what about using the strip command for bdist?
> People who compile from source would get symbols, but the binary
> downloads would be smaller for people who don't care.
>
> - Robert
>
I did a couple of quick tests, and I agree -g does not impact speed.
One program I tried it added 10% to the size. But it may be more/less
on others. Compile time is an issue for many people and lots will
build from source.
But currently you can't rely on there being debug support in Sage. It
is inconsistent from package to package. Some code has -g, other bits
don't. Some spkg-install's add it, some don't.
I believe the variable SAGE_DEBUG was supposed to add debugging
support. If that is so, then it would seem to be sensible to make use
of it and apply it in a consistent manner.
I would have thought it more sensible to build without debug support
by default, and let those that want it add SAGE_DEBUG=1
Some code I noticed add the -p flag, which I think is for profiling.
That I am sure would impact performance. (It's also not portable, as
only gcc uses it).
Dave
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
