[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [incquery-dev] xcore & eiq status
|
Try adjusting the Filters in the lower left corner to make sure not to filter out org.eclipse.*, as most of our code is in that namespace.
I have added you on https://bugs.eclipse.org/bugs/show_bug.cgi?id=428015
I have also added some comments that might give clues on how our builder performance could be significantly improved.
On 07 Apr 2014, at 15:05, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
> I could, but in YourKit I will only see Eclipse Build Job taking the vast majority of the time.
> Do you have any idea how to make the actual job visible?
>
> 2014.04.07. 14:40 keltezéssel, Istvan Rath írta:
>> Can someone run a profiler (e.g. the Java Mission Control http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html which is part of Oracle’s JDK, or YourKit) against the builder scenario to find out who is burning the CPU?
>>
>>
>> On 07 Apr 2014, at 14:21, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:
>>
>>> Hi,
>>>
>>> thanks for the trace. For future reference, I have attached it to the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=428015.
>>>
>>> I checked the trace itself, and my findings are twofolds:
>>> - The NPE thrown in the type provider is clearly erroneous. I have pushed a (quick) fix to the master.
>>> - After the NPEs the builder seems to legitimately called multiple times:
>>> 1. The change in the metamodel triggered a rebuild of the domain, edit, editor projects (Java)
>>> 2. The change in the metamodel invalidated the eiq file.
>>> 3. The eiq file change did not cause a rebuild for the Xcore.
>>>
>>> In other words, either this exception siderailed the builder (in that case it is fixed), or if I understood the trace correctly, I don't really see a way to largely reduce the number of required builds because of the circular dependencies between the xcoreiq and the eiq files.
>>>
>>> Cheers,
>>> Zoli
>>> -- Zoltán Ujhelyi
>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>>
>>> Fault Tolerant Systems Research Group
>>> Budapest University of Technology and Economics
>>>
>>> On 2014.04.07., at 12:57, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>>
>>>> Ok. Regarding point (3), find attached the output of the tracing for the problematic editing scenario.
>>>>
>>>> 2014.04.07. 11:48 keltezéssel, Ujhelyi Zoltán írta:
>>>>> Thanks for checking it. About Eds comment, I repeat myself: "We have said to work amongst the first part; I have tried to look at how EMF does its things, but did not have the time to finish it yet."
>>>>>
>>>>> Zoli
>>>>> On 2014.04.07., at 11:46, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>>>>
>>>>>> Regarding plugin.xml content generation:
>>>>>> I found out (again) that the problem is with the way we modify the contents of the plugin.xml.
>>>>>> The Ecore annotation will not have effect, because the original generated_package extension point lacks the @generated annotation once the IncQuery builder has worked on it.
>>>>>> Ed pointed out the following method: org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.mergePluginXML(String, String, String). Something similar should be used so that the annotation is kept intact.
>>>>>>
>>>>>> 2014.04.06. 9:49 keltezéssel, Ujhelyi Zoltán írta:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Bug 419704 is not solved yet. It will require either throwing out the entire PDE-based plugin.xml loading, or accessing PDE internal stuff to work. We have said to work amongst the first part; I have tried to look at how EMF does its things, but did not have the time to finish it yet.
>>>>>>>
>>>>>>> About (3): I would really like to have some data available of this problematic case.
>>>>>>>
>>>>>>> Tamás: could you please turn on the tracing support of the platform in your run configuration for builders and execute the problematic case? The result would help a lot for determining why are we so slow.
>>>>>>>
>>>>>>> I am attaching a screenshot with my corresponding settings (what is not visible, is not checked on the tracing page). If everything works, the log should contain some information like follows:
>>>>>>>
>>>>>>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Invoking (INCREMENTAL_BUILD) on builder: XtextBuilder(headlessQueries.incquery; [])
>>>>>>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Computing delta for project: headlessQueries.incquery
>>>>>>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Finished computing delta, time: 1ms
>>>>>>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] /headlessQueries.incquery[*]: {}
>>>>>>> Sun Apr 06 09:44:33 CEST 2014 - [Worker-3] Builder finished: XtextBuilder(headlessQueries.incquery; []) time: 2ms
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Zoli
>>>>>>> -- Zoltán Ujhelyi
>>>>>>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>>>>>>>
>>>>>>> Fault Tolerant Systems Research Group
>>>>>>> Budapest University of Technology and Economics
>>>>>>> <Mail Attachment.png>
>>>>>>> On 2014.04.05., at 17:53, Istvan Rath <rath@xxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Thanks for investigating this.
>>>>>>>>
>>>>>>>> Zoli, did we do anything about the (problematic) plugin.xml generation? The last comment on https://bugs.eclipse.org/bugs/show_bug.cgi?id=419704 is from october last year. This might explain (2).
>>>>>>>>
>>>>>>>> We also have a bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=428015) that might be related to (3). Tamas, can you run a profiler to check what is taking a long time in this case?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05 Apr 2014, at 11:32, Tamás Szabó <tamas.szabo@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> A quick overview about the status of the xcore stuff:
>>>>>>>>> (1) The @Ecore annotation doesn't seem to have any effect. If you specify a custom URI, it will not be written to the plugin.xml.
>>>>>>>>> It is also interesting, that the runtime Xtext index contains the EPackage with the new custom URI. The original import in the
>>>>>>>>> eiq files with the package URI "library" will not be valid anymore, you can (and should) use the new one, even if the plugin.xml contains the wrong entry.
>>>>>>>>> This needs to be investigated with the help of Ed.
>>>>>>>>> (2) I am not sure about the plugin.xml rewriting problems, I cant reproduce it deterministically. I tried to erase all the contents of the plugin.xml and invoke the builder again, and the contents have been written properly. Nevertheless, a full clean usually will result in the absence of the gen_package extension point definition and the query specification extension points. The derived feature extension points are always generated.
>>>>>>>>> (3) Performance can be really poor in the xcore & EIQ scenario. Simply adding a new pattern will result in a long building time.
>>>>>>>>> (4) When we reach the point that everything is generated properly into the plugin.xml, then the generated use case works just fine!
>>>>>>>>>
>>>>>>>>> I will address (1), but I am going to need help with (2).
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Tomi
>>>>>>>>> _______________________________________________
>>>>>>>>> incquery-dev mailing list
>>>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>>>> Istvan Rath, PhD
>>>>>>>> Research Fellow
>>>>>>>> Fault Tolerant Systems Research Group
>>>>>>>> Budapest University of Technology and Economics
>>>>>>>> rath@xxxxxxxxxx
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> incquery-dev mailing list
>>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> incquery-dev mailing list
>>>>>>>
>>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>>> --
>>>>>> Tamás Szabó
>>>>>> Software Engineer
>>>>>>
>>>>>> Tel.: +49 711 342 191 0
>>>>>> Fax.: +49 711 342 191 29
>>>>>> Mobil: +49 171 565 416 9
>>>>>> Web:
>>>>>> www.itemis.de
>>>>>>
>>>>>> Mail:
>>>>>> tamas.szabo@xxxxxxxxx
>>>>>>
>>>>>> Skype: szabta89
>>>>>>
>>>>>> itemis AG
>>>>>> Niederlassung Süd
>>>>>> Meitnerstr. 10
>>>>>> 70563 Stuttgart
>>>>>>
>>>>>> Rechtlicher Hinweis:
>>>>>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>>>>>> Lünen
>>>>>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>>>>>> Pietrek | Jens Trompeter | Sebastian Neus
>>>>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>>>>>> | Michael Neuhaus
>>>>>>
>>>>>> _______________________________________________
>>>>>> incquery-dev mailing list
>>>>>> incquery-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>>> _______________________________________________
>>>>> incquery-dev mailing list
>>>>> incquery-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>>> --
>>>> Tamás Szabó
>>>> Software Engineer
>>>>
>>>> Tel.: +49 711 342 191 0
>>>> Fax.: +49 711 342 191 29
>>>> Mobil: +49 171 565 416 9
>>>> Web: www.itemis.de
>>>> Mail: tamas.szabo@xxxxxxxxx
>>>> Skype: szabta89
>>>>
>>>> itemis AG
>>>> Niederlassung Süd
>>>> Meitnerstr. 10
>>>> 70563 Stuttgart
>>>>
>>>> Rechtlicher Hinweis:
>>>> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
>>>> Lünen
>>>> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
>>>> Pietrek | Jens Trompeter | Sebastian Neus
>>>> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
>>>> | Michael Neuhaus
>>>>
>>>> <tracing_iq.txt>_______________________________________________
>>>> incquery-dev mailing list
>>>> incquery-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>> _______________________________________________
>>> incquery-dev mailing list
>>> incquery-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>> Istvan Rath, PhD
>> Research Fellow
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>> rath@xxxxxxxxxx
>>
>>
>>
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>
> --
> Tamás Szabó
> Software Engineer
>
> Tel.: +49 711 342 191 0
> Fax.: +49 711 342 191 29
> Mobil: +49 171 565 416 9
> Web: www.itemis.de
> Mail: tamas.szabo@xxxxxxxxx
> Skype: szabta89
>
> itemis AG
> Niederlassung Süd
> Meitnerstr. 10
> 70563 Stuttgart
>
> Rechtlicher Hinweis:
> Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft:
> Lünen
> Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Dr. Georg
> Pietrek | Jens Trompeter | Sebastian Neus
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vorsitzender) | Stephan Grollmann
> | Michael Neuhaus
>
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev
Istvan Rath, PhD
Research Fellow
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
rath@xxxxxxxxxx
