OK, fair enough. So the suggestion currently on the table is:
* Remove "profile" build mode. * Add a build-time switch that will use -g on the optimized mode, defaulting to off. * Distributions that have policies requiring a build with symbols can choose either an optimized build with symbols, or a full DEBUG mode (that will have bad performance because it avoids certain optimization and has lots more assertions and other checks designed to find legit bugs in the OIIO library). > On Jan 11, 2016, at 3:54 PM, Malcolm Humphreys <[email protected]> > wrote: > > I think it should be the other way around as I expect production builds to be > smallest possible to speed up any IO when software is installed on network > storage. > > It’s a bit like saying your expecting the software to crash so make the > library 3x bigger.. OIIO is pretty stable in most places I see it used and > only is unstable with any of the bleeding edge dev. > > I do expect the debug build to be as fast as the production one but just with > all the symbols so a trace makes some sense. > > .malcolm > >> On 11 Jan 2016, at 10:25 pm, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> >> That sounds to me like a small price to pay in order to always have a clean >> stack trace and be able to profile without a recompile. >> >> We can add a build-time flag to force not using -g, for those who really >> don't want to pay for the 70M. >> >> Does that sound reasonable? Or do you think the default should be the other >> way around? (Keep optimized build as it is, eliminate separate "profile" >> mode, and simply have a build-time flag to turn on -g?) >> >> >> >>> On Jan 11, 2016, at 2:12 PM, Thiago Ize <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> My understanding is the only issue is the library takes up more space on >>> disk. On my mac with OIIO 1.5, it increases the libOpenImageIO.a from 25MB >>> to 92MB. >>> >>> On Mon, Jan 11, 2016 at 12:28 PM, Larry Gritz <[email protected] >>> <mailto:[email protected]>> wrote: >>> Is there a down-side to using -g to include the symbols for all optimized >>> builds? Does it make the library or binaries dramatically bigger? (You can >>> always strip binaries to fix that.) >>> >>> There are no secrecy- or security-based reasons to avoid symbols, as you >>> might for a commercial product. >>> >>> Maybe eliminate profile mode entirely, have the optimized build use -g by >>> default, but have a build-time option to not embed the symbols, for anybody >>> who really needs to squeeze out that last bit of storage? >>> >>> >>>> On Jan 11, 2016, at 11:19 AM, Thiago Ize <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> I think profile mode should be the same as release mode but with -g added >>>> in, otherwise it's possible I'll waste time trying to optimize a hotspot >>>> in -O2 that doesn't exist in the -O3 build. Furthermore, this would make >>>> it simple for the fedora/debian/etc... builds to build with symbols -- >>>> they just choose profile mode and be done with it. >>>> >>>> On Mon, Jan 11, 2016 at 12:11 PM, Larry Gritz <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> There is nothing sacred about the current profile mode. If a different set >>>> of flags would be more useful, let's change it. >>>> >>>> -- lg >>>> >>>> >>>> > On Jan 11, 2016, at 7:26 AM, Thiago Ize <[email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > >>>> > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" >>>> > (-O0, -g). If you're actually building in debug mode and then stripping >>>> > symbols, all your users are now getting a really slow and crappy OIIO >>>> > without any optimizations. What you want is to just add the debug >>>> > symbols (-g) to the release mode. Ideally the profile mode would do >>>> > this for you, but I think the profile mode in OIIO uses different >>>> > optimization settings, which makes it kind of useless (you want to >>>> > profile the real code made with -O3, not the -O2 code). >>>> > >>>> > >>> >>> -- >>> Larry Gritz >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
