xmlvm-developers

[xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

Hello!

I remember this discussion in the past, but I would like to bring it up again.
From my understanding, the C backend right now computates on the fly the required classes and adds only those to the Xcode project.
Since now in C the handling of library should be more optimized, I think that it would be very interesting to use the library (which will also reduce compile time to minimum) and will make this class optimization obsolete.

What do you think?

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

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

On Fri, Jun 10, 2011 at 11:00 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> Hello!
>
> I remember this discussion in the past, but I would like to bring it up
> again.
> >From my understanding, the C backend right now computates on the fly the
> required classes and adds only those to the Xcode project.
> Since now in C the handling of library should be more optimized, I think
> that it would be very interesting to use the library (which will also reduce
> compile time to minimum) and will make this class optimization obsolete.
>
> What do you think?
>
> ------------------------------------------------------------------------------
> 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
>

Re: [xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

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? 

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

Ah now I see, thanks for the explanation. I am curious to what Arno has to
say about this, as I am not in this matter too deeply. However, I know that
we are doing several optimizations on the files in the C-backend when we
know that a certain set of classes doesn't exist.

One functionality we have right now is introducing special error methods
that stop the execution of the program, if a "red class" is hit. This makes
sense for classes we are not sure actually work at all for example.

Also I wonder if the linking process would then not take a lot of time and
if the time speed-up would then be really that much.

Just thinking out loud ... I let Arno comment on it, who knows much better
to evaluate the situation.

// Sascha

2011/6/10 Panayotis Katsaloulis <pan...@pa...>

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

Re: [xmlvm-dev] C backend and library

[Arno P. <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

Re: [xmlvm-dev] C backend and library

[Sascha H. <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
>

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

Re: [xmlvm-dev] C backend and library

[Arno P. <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...>

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

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

Re: [xmlvm-dev] C backend and library

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

Forgot to mention: Alternatively we could color the app with a safe offset
(e.g. 100) to avoid clashes in "development mode". But that would blow up
tib sizes quite a bit.

2011/6/10 Markus Neubrand <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
>>>
>>>
>>
>

Re: [xmlvm-dev] C backend and library

[Arno P. <ar...@pu...>]

I think that is a good idea! For development mode the size of the itable
does not matter.

Arno

On Jun 10, 2011, at 10:02 AM, Markus Neubrand <mar...@gm...>
wrote:

Forgot to mention: Alternatively we could color the app with a safe offset
(e.g. 100) to avoid clashes in "development mode". But that would blow up
tib sizes quite a bit.

2011/6/10 Markus Neubrand <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
>>>
>>>
>>
>

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

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

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

Re: [xmlvm-dev] C backend and library

[Arno P. <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...> 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...>

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

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

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

>
> 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...> 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...>
>
>>
>> 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...> 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...>
>>
>>> 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...>
>>>
>>>> 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...> 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
>>>> > _______________________________________________
>>>> > Xmlvm-developers mailing list
>>>> > <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
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> _______________________________________________
>>>> Xmlvm-developers mailing list
>>>>  <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
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> _______________________________________________
>>> Xmlvm-developers mailing list
>>>  <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
>>>
>>>
>>
>

Re: [xmlvm-dev] C backend and library

[Arno P. <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...>

>
> 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...> 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...>
>
>>
>> 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...> 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...>
>>
>>> 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...>
>>>
>>>> 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...> 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
>>>> > _______________________________________________
>>>> > Xmlvm-developers mailing list
>>>> > <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
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> _______________________________________________
>>>> Xmlvm-developers mailing list
>>>>  <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
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> _______________________________________________
>>> Xmlvm-developers mailing list
>>>  <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
>>>
>>>
>>
>

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

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

Re: [xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

On Jun 10, 2011, at 7:26 PM, Sascha Haeberling wrote:

> Ah gotcha. Any way to make that more stable so that not so many source files need to be changed?


I am sure if this is relevant, but with the build patch I am proposing, there is a step which will touch a file ONLY if the contents of this file is changed.

Re: [xmlvm-dev] C backend and library

[Arno P. <ar...@pu...>]

Interfaces.h will change whenever you make any change to a Java interface or
the way it is used. In this case the only option is a complete
recompilation.

What might already help if files that are written by an OutputProcess first
check if the file already exists and has identical content. Of course that
will slow down things a little more but might save time with Xcode.

Arno

On Jun 10, 2011, at 10:26 AM, Sascha Haeberling <sa...@gm...> wrote:

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

Re: [xmlvm-dev] C backend and library

[Sascha H. <sa...@gm...>]

I have to check when I am home, but I already do that in some cases. E.g. I
also ended up doing this for the JS output, because Qooxdoo had exactly the
same issue. It recompiled everything because of the timestamp changes. Once
that was fixed, it was sped up quite a bit

// Sascha

On Fri, Jun 10, 2011 at 6:40 PM, Arno Puder <ar...@pu...> wrote:

>
> Interfaces.h will change whenever you make any change to a Java interface
> or the way it is used. In this case the only option is a complete
> recompilation.
>
> What might already help if files that are written by an OutputProcess first
> check if the file already exists and has identical content. Of course that
> will slow down things a little more but might save time with Xcode.
>
> Arno
>
>
> On Jun 10, 2011, at 10:26 AM, Sascha Haeberling <sa...@gm...> wrote:
>
> 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...>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...>
>> 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...>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...>
>>> 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...>
>>> 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...>
>>>> 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...>
>>>> 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...>
>>>>> 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...>
>>>>>> 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>
>>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>>> > _______________________________________________
>>>>>> > Xmlvm-developers mailing list
>>>>>> > <Xml...@li...><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>
>>>>>> 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>
>>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>>> _______________________________________________
>>>>>> Xmlvm-developers mailing list
>>>>>>  <Xml...@li...><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>
>>>>>> 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>
>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>> _______________________________________________
>>>>> Xmlvm-developers mailing list
>>>>>  <Xml...@li...><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>
>>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [xmlvm-dev] C backend and library

[Paul P. <bay...@gm...>]

I have already been using optimizations regarding this topic.  I use "rsync"
with options "-zvrc".  There are 2 obstacles, one of which is very easy to
overcome & the other I'll let someone else answer.

This only speeds up XCode compile time, but that's the significant portion.
 The way it works is it XMLVM compiles as normal into a temporary directory.
 Then rsync copies all new or changed files to the destination directory.
 Any unchanged files are left there & so XCode does not recompile them.  If
you deleted any files, note they'll still be in the destination directory
until you clean it out, but that doesn't matter most of the time.  You could
add an rsync option to delete them, but that would also delete the ".o"
files & cause a full recompile.

You can use rsync easily via Unix or on a Mac & with a little extra work in
Windows via Cygwin.

The 2 obstacles:

   1. The vtable entries are randomly ordered, so the files change
   unnecessarily causing recompile.  I just changed the
   VtableOutputProcess.java to order alphabetically & problem solved.
   2. Adding/removing String constants causes the index number to change in
   other files, causing the other files to recompile unnecessarily.  Would that
   be easy to lock down index numbers in API classes?  I.e. give them the first
   numbers?


Paul



2011/6/10 Sascha Haeberling <sa...@gm...>

> I have to check when I am home, but I already do that in some cases. E.g. I
> also ended up doing this for the JS output, because Qooxdoo had exactly the
> same issue. It recompiled everything because of the timestamp changes. Once
> that was fixed, it was sped up quite a bit
>
> // Sascha
>
>
> On Fri, Jun 10, 2011 at 6:40 PM, Arno Puder <ar...@pu...> wrote:
>
>>
>> Interfaces.h will change whenever you make any change to a Java interface
>> or the way it is used. In this case the only option is a complete
>> recompilation.
>>
>> What might already help if files that are written by an OutputProcess
>> first check if the file already exists and has identical content. Of course
>> that will slow down things a little more but might save time with Xcode.
>>
>> Arno
>>
>>
>> On Jun 10, 2011, at 10:26 AM, Sascha Haeberling <sa...@gm...>
>> wrote:
>>
>> 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...>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...>
>>> 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...>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...>
>>>> 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...>
>>>> 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...>
>>>>> 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...>
>>>>> 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...>
>>>>>> 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...>
>>>>>>> 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>
>>>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>>>> > _______________________________________________
>>>>>>> > Xmlvm-developers mailing list
>>>>>>> > <Xml...@li...><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>
>>>>>>> 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>
>>>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>>>> _______________________________________________
>>>>>>> Xmlvm-developers mailing list
>>>>>>>  <Xml...@li...><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>
>>>>>>> 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>
>>>>>> http://p.sf.net/sfu/ephox-dev2dev
>>>>>> _______________________________________________
>>>>>> Xmlvm-developers mailing list
>>>>>>  <Xml...@li...><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>
>>>>>> 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
>
>

Re: [xmlvm-dev] C backend and library

[Arno P. <ar...@pu...>]

On Jun 10, 2011, at 10:01 AM, Paul Poley <bay...@gm...> wrote:

You can use rsync easily via Unix or on a Mac & with a little extra work in
Windows via Cygwin.


Hopefully we can integrate a similar behavior into the XMLVM pipeline.


The 2 obstacles:

   1. The vtable entries are randomly ordered, so the files change
   unnecessarily causing recompile.  I just changed the
   VtableOutputProcess.java to order alphabetically & the problem solved.


Can you please commit this to the HEAD? This would also be useful to make
gen-c-wrapper deterministic.


   1. Adding/removing String constants causes the index number to change in
   other files, causing the other files to recompile unnecessarily.  Would that
   be easy to lock down index numbers in API classes?  I.e. give them the first
   numbers?


Good question. I had forgotten about the constant pool. Perhaps a similar
approach to what Markus suggested for the itables. I'll give it some
thought.

Arno

Re: [xmlvm-dev] C backend and library

[Paul P. <bay...@gm...>]

I have committed the change to sort the vtable entries.

Paul

On Sat, Jun 11, 2011 at 12:58 AM, Arno Puder <ar...@pu...> wrote:

>
>
> On Jun 10, 2011, at 10:01 AM, Paul Poley <bay...@gm...> wrote:
>
> You can use rsync easily via Unix or on a Mac & with a little extra work in
> Windows via Cygwin.
>
>
> Hopefully we can integrate a similar behavior into the XMLVM pipeline.
>
>
> The 2 obstacles:
>
>    1. The vtable entries are randomly ordered, so the files change
>    unnecessarily causing recompile.  I just changed the
>    VtableOutputProcess.java to order alphabetically & the problem solved.
>
>
> Can you please commit this to the HEAD? This would also be useful to make
> gen-c-wrapper deterministic.
>
>
>    1. Adding/removing String constants causes the index number to change
>    in other files, causing the other files to recompile unnecessarily.  Would
>    that be easy to lock down index numbers in API classes?  I.e. give them the
>    first numbers?
>
>
> Good question. I had forgotten about the constant pool. Perhaps a similar
> approach to what Markus suggested for the itables. I'll give it some
> thought.
>
> Arno
>
>
>
>

Re: [xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

On Jun 10, 2011, at 8:01 PM, Paul Poley wrote:

> I have already been using optimizations regarding this topic.  I use "rsync" with options "-zvrc".  There are 2 obstacles, one of which is very easy to overcome & the other I'll let someone else answer.
> 
> This only speeds up XCode compile time, but that's the significant portion.  The way it works is it XMLVM compiles as normal into a temporary directory.  Then rsync copies all new or changed files to the destination directory.  Any unchanged files are left there & so XCode does not recompile them.  If you deleted any files, note they'll still be in the destination directory until you clean it out, but that doesn't matter most of the time.  You could add an rsync option to delete them, but that would also delete the ".o" files & cause a full recompile.
> 
> You can use rsync easily via Unix or on a Mac & with a little extra work in Windows via Cygwin.

Sorry for the double post.
This is more or less what is doing the build step I was talking about.

Re: [xmlvm-dev] C backend and library

[Panayotis K. <pan...@pa...>]

First, some results:

1) The optimization of not touching a file if it remains the same is working and you could check it for yourself, in the SVN version.
2) C backend (with iFireworks) works fine in the iOS 5 
3) Xcode still freezes, when the number of errors are over 1000.


And now some questions:

1) Let's take for example the files java_util_ArrayList.m/h . This class gets overridden in my code by another class. Will the contents of java_util_ArrayList.m/h change, depending on the overriding class?
2) Is it possible (since most of it is generated code),  to write code (probably with some casting) which will silence these 999+ warnings?

Re: [xmlvm-dev] C backend and library

[Arno P. <ar...@pu...>]

On Jun 11, 2011, at 3:37 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:

> And now some questions:
>
> 1) Let's take for example the files java_util_ArrayList.m/h . This class gets overridden in my code by another class. Will the contents of java_util_ArrayList.m/h change, depending on the overriding class?

Possibly yes. The method may not have been in the vtable but by
overriding it, it needs to be added to the vtable of ArrayList.

> 2) Is it possible (since most of it is generated code),  to write code (probably with some casting) which will silence these 999+ warnings?

The clean solution is to generate better code. In the meantime just
select the option "inhibit all warnings".

Arno
>