Re: [xmlvm-dev] C backend and library

[Markus N. <mar...@gm...>]

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
>
>