Re: [xmlvm-dev] C backend and library

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

We would still need to store the selector graph: A class in the app could
implement its own interface as well as implement a JDK interface at the same
time. For this case I need to know how the original JDK interface was
colored to avoid clashes.

For the vtable optimization implementing the "development mode" should be
simple.

2011/6/10 Arno Puder <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...>
> 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...>
>
>> 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...>
>>
>>> 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...> 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
>>> > _______________________________________________
>>> > Xmlvm-developers mailing list
>>> > <Xml...@li...>
>>> Xml...@li...
>>> > <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
>>> _______________________________________________
>>> Xmlvm-developers mailing list
>>>  <Xml...@li...>
>>> Xml...@li...
>>>  <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
>> _______________________________________________
>> Xmlvm-developers mailing list
>>  <Xml...@li...>
>> Xml...@li...
>>  <https://lists.sourceforge.net/lists/listinfo/xmlvm-developers>
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>>
>>
>