Menu
▾
▴
Re: [xmlvm-dev] C backend and library
|
From: Sascha H. <sa...@gm...> - 2011-06-10 16:26:38
|
Ah gotcha. Any way to make that more stable so that not so many source files need to be changed? 2011/6/10 Arno Puder <ar...@pu...> > > Yep. Xcode starts from scratch every time. But as you said, that is not > really Xcodes fault since we regenerate all the files every single time. > Note overwriting files is one thing, but remember that interfaces.h is > recomputed every single time which then requires all .m source files to be > recompiled as well. > > Arno > > > On Jun 10, 2011, at 10:18 AM, Sascha Haeberling <sa...@gm...> wrote: > > So XCode starts totally from scratch every time you make a change? I almost > cannot believe that. Maybe it would help if we wouldn't change the > timestamps of files that haven't changed? > > 2011/6/10 Arno Puder < <ar...@pu...>ar...@pu...> > >> >> Real numbers would be helpful. The problem with caching is that we can >> only do this in XMLVM but not in Xcode. Xcode already take a long time to >> compile. How much time it takes to link against a huge library by comparison >> we don't know. >> >> Arno >> >> >> On Jun 10, 2011, at 10:03 AM, Sascha Haeberling < <sa...@gm...> >> sa...@gm...> wrote: >> >> I would really be interesting it getting some actual numbers. At work I >> often see huge binaries link forever. So if we put the whole JDK >> cross-compiled into one library, I wonder how long that would take. >> >> Also keep in mind that another alternative to speeding things up is to >> have proper caching of things at various stages. That could speed things up >> quite a bit I suspect. >> >> // Sascha >> >> 2011/6/10 Arno Puder < <ar...@pu...> <ar...@pu...>ar...@pu...> >> >>> >>> I'm thinking of a "development mode" where no optimizations are >>> performed. For vtable this means that all methods go into the vtable by >>> default. That should be much easier than disabling itable optimizations. >>> >>> With regards to time savings: I suspect that a library would be >>> beneficial. Keep in mind that compile time includes XMLVM compile time as >>> well as Xcode compile time. XMLVM would only need to compile the application >>> without computing the transitive closure of all referenced classes (let >>> alone cross compiling these classes) and Xcode would "only" need to link a >>> huge library (where I suspect that that will be faster than compiling >>> everything). But of course I don't have empirical evidence. >>> >>> Arno >>> >>> >>> On Jun 10, 2011, at 9:21 AM, Markus Neubrand <<mar...@gm...><mar...@gm...> >>> mar...@gm...> wrote: >>> >>> Hi, >>> >>> For the vtable optimization for non-overridden methods I don't see a >>> possibility to do this at all. If we compile everything into a library we >>> never know when a class of the application overrides something in the JDK, >>> etc. >>> >>> For the selector coloring we could implement a possibility to save the >>> end state of the colored graph for the library and use this information when >>> we color the selector graph of the application. >>> >>> But I agree with Sascha: it would be nice to know if this would speed >>> things up significantly before we start with something like that. >>> >>> Markus >>> >>> 2011/6/10 Sascha Haeberling < <sa...@gm...> <sa...@gm...><sa...@gm...> >>> sa...@gm...> >>> >>>> Are we even sure that linking against such a huge library would really >>>> be that much faster? From my experience linking huge binaries can take a >>>> long time as well. >>>> >>>> In the end it looks like this: timeSaved = (timePipelineNow - >>>> timePipelineThen) - timeLinking >>>> >>>> If the times saved is small, the question is whether it makes sense >>>> investing time into it at all. Therefore it would be good to have some >>>> estimates first. >>>> >>>> // Sascha >>>> >>>> >>>> 2011/6/10 Arno Puder < <ar...@pu...> <ar...@pu...><ar...@pu...> >>>> ar...@pu...> >>>> >>>>> Yes, we've had this discussion before. Basically creating a Unix-like >>>>> library (.a) that speeds things compilation time. However, the problem >>>>> is that (at least) for now it wouldn't work with the C backend. We do >>>>> optimizations that go beyond the simple decision "should this file be >>>>> included or not" (what the linker typically does, and which, btw, is >>>>> also performed by XMLVM at compile-time). We also optimize things like >>>>> vtables, e.g., if a method never gets overridden, it will not end up >>>>> in the vtable. This knowledge, however, only exists if we take the >>>>> application into account. If the application overrides a library >>>>> method, then the cross-compilation of the library also needs to >>>>> change. >>>>> >>>>> I agree that for a regular development cycle it would make sense to >>>>> have something like a library and only do full optimizations for the >>>>> final release. We would need a way to cross-compile without >>>>> optimizations. One big problem I see here are interface methods >>>>> (because of the selector coloring scheme that is used), but I better >>>>> let Markus respond to this since he implemented those optimizations. >>>>> >>>>> Arno >>>>> >>>>> >>>>> On Jun 10, 2011, at 6:26 AM, Panayotis Katsaloulis >>>>> < <pan...@pa...> <pan...@pa...><pan...@pa...> >>>>> pan...@pa...> wrote: >>>>> >>>>> > >>>>> > On 10 Ιουν 2011, at 3:11 μ.μ., Sascha Haeberling wrote: >>>>> > >>>>> >> Panayotis, >>>>> >> >>>>> >> sorry, I didn't understand what you mean. What do you mean by "the >>>>> library"? The C backend does compute all dependencies so that the number of >>>>> classes that are compiled and outputted in the end is at a minimum. Only >>>>> required classes will be pulled in. Why would you want to replace this and >>>>> with what? >>>>> >> >>>>> >> // Sascha >>>>> > >>>>> > >>>>> > This is from an old discussion. >>>>> > >>>>> > The idea is to compile the whole JDK and iPhone compatibility library >>>>> (and probably other dependencies) into a C library (i.e. in a form of .a >>>>> file) and compile the project against this library. >>>>> > Thus the Xcode project will compile much much faster and even the >>>>> production of the Xcode project will be faster (and smaller) since no files >>>>> from the JDK and the compatibility library will be required any more. >>>>> > >>>>> > This idea was also in the earlier days of ObjC backend, but due to >>>>> the way ObjC handled dependencies and late binding, the gain was far less. >>>>> > Now with the strong typed C language, things should be much better. >>>>> > >>>>> > For example, if a function is not used at all, the C compiler >>>>> understands that and never embeds it into the output binary - we have >>>>> optimizations in the method-level, instead of the class-level. >>>>> > >>>>> > >>>>> > I don't know how virtual functions are handled and probably Arno >>>>> could help with this. >>>>> > >>>>> > >>>>> > PS: I remember that ProGuard is also able to perform this type of >>>>> optimizations and it is already used for this reason in Android projects. >>>>> Probably we should also do something similar? >>>>> > >>>>> ------------------------------------------------------------------------------ >>>>> > EditLive Enterprise is the world's most technically advanced content >>>>> > authoring tool. Experience the power of Track Changes, Inline Image >>>>> > Editing and ensure content is compliant with Accessibility Checking. >>>>> > <http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev> >>>>> http://p.sf.net/sfu/ephox-dev2dev >>>>> > _______________________________________________ >>>>> > Xmlvm-developers mailing list >>>>> > <Xml...@li...><Xml...@li...><Xml...@li...> >>>>> Xml...@li... >>>>> > <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> EditLive Enterprise is the world's most technically advanced content >>>>> authoring tool. Experience the power of Track Changes, Inline Image >>>>> Editing and ensure content is compliant with Accessibility Checking. >>>>> <http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev> >>>>> http://p.sf.net/sfu/ephox-dev2dev >>>>> _______________________________________________ >>>>> Xmlvm-developers mailing list >>>>> <Xml...@li...><Xml...@li...><Xml...@li...> >>>>> Xml...@li... >>>>> <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> EditLive Enterprise is the world's most technically advanced content >>>> authoring tool. Experience the power of Track Changes, Inline Image >>>> Editing and ensure content is compliant with Accessibility Checking. >>>> <http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev><http://p.sf.net/sfu/ephox-dev2dev> >>>> http://p.sf.net/sfu/ephox-dev2dev >>>> _______________________________________________ >>>> Xmlvm-developers mailing list >>>> <Xml...@li...><Xml...@li...><Xml...@li...> >>>> Xml...@li... >>>> <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers><https://lists.sourceforge.net/lists/listinfo/xmlvm-developers> >>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers >>>> >>>> >>> >> > |
