From: Arno P. <ar...@pu...> - 2011-06-10 15:58:08
|
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...> 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...> > 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...> > >> 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...> 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 >> > _______________________________________________ >> > Xmlvm-developers mailing list >> > Xml...@li... >> > 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 >> _______________________________________________ >> Xmlvm-developers mailing list >> Xml...@li... >> 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 > _______________________________________________ > Xmlvm-developers mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-developers > > |