You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Fabian Lange <fa...@codecentric.de> on 2017/08/09 08:46:24 UTC
Re: Removal of JaxBUtil ?
Hey,
I have new intel on this. A colleague generated a flame graph.
I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
parsing.
It is about 25% of the overall startup time just to boot up the jaxb
infrastructure.
Fabian
On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <fa...@codecentric.de>
wrote:
> Thanks, good hint.
> For those inclined to understand my request, attached is the output of
> -XX:+TraceClassLoading
>
> Using the xml binding feature approximately loads 800 classes (which
> represent about 5MB memory)
>
> I haven't checked alternatives to the jaxb. And I am aware that this is a
> more esoteric requirement to reduce footprint.
>
> However, I am sure if this would not be from the JDK, nobody would pull in
> a 5MB dependency to parse a single xml file.
>
> Fabian
>
>
> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <gn...@apache.org>
> wrote:
>
>> Note that on older branches, the feature repositories are still parsed
>> using DOM
>> https://github.com/apache/karaf/blob/karaf-2.x/features/
>> core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>
>> The xml is now also written, that may be the reason why we switched.
>>
>> 2016-07-14 23:11 GMT+02:00 Fabian Lange <fa...@codecentric.de>:
>>
>> > Hi,
>> >
>> > i am looking into ways to trim down Karaf. I notices that Karaf uses
>> JaxB
>> > to parse features.xml - However this is the only application of JaxB.
>> >
>> > Could somebody more involved help me to figure out if it is worth to
>> > replace it with manual marshalling? I assume other xmls are parsed
>> > differently?
>> > Advantage would be that the whole jaxb infrastructure could be avoided,
>> > including the contexts.
>> >
>> > I know manual parsing is a pain, but anyway, just wanted to throw this
>> out,
>> > maybe somebody has a good suggestion.
>> >
>> > Fabian
>> > --
>> > Fabian Lange | Performance Expert
>> > mobil: +49 (0) 160.3673393
>> >
>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>> >
>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
>> Schütz
>> >
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>
>
Re: Removal of JaxBUtil ?
Posted by Daniel Kulp <dk...@apache.org>.
Why not just use the StAX API’s built into the JDK to avoid another dependency? That said, it’s likely using StAX might/should bring in woodstox.
Dan
> On Aug 9, 2017, at 5:11 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Fair enough. Agree, worth to evaluate xmlpullparser.
>
> Regards
> JB
>
> On 08/09/2017 11:04 AM, Fabian Lange wrote:
>> I cannot really tell.
>> Whatever XML stream or Document parser we would use, it also would load new
>> classes and require some time to initialize.
>> JAXB is however known to be the most inefficient in that regard. On the
>> other hand it offers the most convenience because you get these nice mapped
>> POJOs.
>> Felix SCR does it manually as far as I can see:
>> https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
>> Felix IPojo uses sax:
>> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
>> Felix metatype uses xmlpullparser:
>> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java
>> None of Felix uses jaxb.
>> Maybe its worth giving xmlpullparser a shot. The code of metatype looks
>> straigtforward, and the embedded classes are minimal.
>> Fabian
>> On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>> Hi Fabian,
>>>
>>> interesting fact indeed. What alternate do you propose ?
>>>
>>> Regards
>>> JB
>>>
>>> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>>>
>>>> Hey,
>>>> I have new intel on this. A colleague generated a flame graph.
>>>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>>>> parsing.
>>>>
>>>> It is about 25% of the overall startup time just to boot up the jaxb
>>>> infrastructure.
>>>>
>>>> Fabian
>>>>
>>>>
>>>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>>>> fabian.lange@codecentric.de <ma...@codecentric.de>> wrote:
>>>>
>>>> Thanks, good hint.
>>>> For those inclined to understand my request, attached is the output of
>>>> -XX:+TraceClassLoading
>>>>
>>>> Using the xml binding feature approximately loads 800 classes (which
>>>> represent about 5MB memory)
>>>>
>>>> I haven't checked alternatives to the jaxb. And I am aware that this
>>>> is a
>>>> more esoteric requirement to reduce footprint.
>>>>
>>>> However, I am sure if this would not be from the JDK, nobody would
>>>> pull in a
>>>> 5MB dependency to parse a single xml file.
>>>>
>>>> Fabian
>>>>
>>>>
>>>> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <gnodet@apache.org
>>>> <ma...@apache.org>> wrote:
>>>>
>>>> Note that on older branches, the feature repositories are still
>>>> parsed
>>>> using DOM
>>>> https://github.com/apache/karaf/blob/karaf-2.x/features/core
>>>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>>> <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>>>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>>>
>>>> The xml is now also written, that may be the reason why we
>>>> switched.
>>>>
>>>> 2016-07-14 23:11 GMT+02:00 Fabian Lange <
>>>> fabian.lange@codecentric.de
>>>> <ma...@codecentric.de>>:
>>>>
>>>> > Hi,
>>>> >
>>>> > i am looking into ways to trim down Karaf. I notices that
>>>> Karaf uses JaxB
>>>> > to parse features.xml - However this is the only application
>>>> of JaxB.
>>>> >
>>>> > Could somebody more involved help me to figure out if it is
>>>> worth to
>>>> > replace it with manual marshalling? I assume other xmls are
>>>> parsed
>>>> > differently?
>>>> > Advantage would be that the whole jaxb infrastructure could be
>>>> avoided,
>>>> > including the contexts.
>>>> >
>>>> > I know manual parsing is a pain, but anyway, just wanted to
>>>> throw
>>>> this out,
>>>> > maybe somebody has a good suggestion.
>>>> >
>>>> > Fabian
>>>> > --
>>>> > Fabian Lange | Performance Expert
>>>> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>>>> >
>>>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>>>> Deutschland
>>>> >
>>>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>>>> Wuppertal
>>>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>>>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>>>> Jürgen
>>>> Schütz
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com <ma...@redhat.com>
>>>> Web: http://fusesource.com
>>>> Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Removal of JaxBUtil ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Fair enough. Agree, worth to evaluate xmlpullparser.
Regards
JB
On 08/09/2017 11:04 AM, Fabian Lange wrote:
> I cannot really tell.
> Whatever XML stream or Document parser we would use, it also would load new
> classes and require some time to initialize.
>
> JAXB is however known to be the most inefficient in that regard. On the
> other hand it offers the most convenience because you get these nice mapped
> POJOs.
>
> Felix SCR does it manually as far as I can see:
> https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
> Felix IPojo uses sax:
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
> Felix metatype uses xmlpullparser:
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java
>
> None of Felix uses jaxb.
>
> Maybe its worth giving xmlpullparser a shot. The code of metatype looks
> straigtforward, and the embedded classes are minimal.
>
> Fabian
>
>
> On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Fabian,
>>
>> interesting fact indeed. What alternate do you propose ?
>>
>> Regards
>> JB
>>
>> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>>
>>> Hey,
>>> I have new intel on this. A colleague generated a flame graph.
>>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>>> parsing.
>>>
>>> It is about 25% of the overall startup time just to boot up the jaxb
>>> infrastructure.
>>>
>>> Fabian
>>>
>>>
>>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>>> fabian.lange@codecentric.de <ma...@codecentric.de>> wrote:
>>>
>>> Thanks, good hint.
>>> For those inclined to understand my request, attached is the output of
>>> -XX:+TraceClassLoading
>>>
>>> Using the xml binding feature approximately loads 800 classes (which
>>> represent about 5MB memory)
>>>
>>> I haven't checked alternatives to the jaxb. And I am aware that this
>>> is a
>>> more esoteric requirement to reduce footprint.
>>>
>>> However, I am sure if this would not be from the JDK, nobody would
>>> pull in a
>>> 5MB dependency to parse a single xml file.
>>>
>>> Fabian
>>>
>>>
>>> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <gnodet@apache.org
>>> <ma...@apache.org>> wrote:
>>>
>>> Note that on older branches, the feature repositories are still
>>> parsed
>>> using DOM
>>> https://github.com/apache/karaf/blob/karaf-2.x/features/core
>>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>> <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>>
>>> The xml is now also written, that may be the reason why we
>>> switched.
>>>
>>> 2016-07-14 23:11 GMT+02:00 Fabian Lange <
>>> fabian.lange@codecentric.de
>>> <ma...@codecentric.de>>:
>>>
>>> > Hi,
>>> >
>>> > i am looking into ways to trim down Karaf. I notices that
>>> Karaf uses JaxB
>>> > to parse features.xml - However this is the only application
>>> of JaxB.
>>> >
>>> > Could somebody more involved help me to figure out if it is
>>> worth to
>>> > replace it with manual marshalling? I assume other xmls are
>>> parsed
>>> > differently?
>>> > Advantage would be that the whole jaxb infrastructure could be
>>> avoided,
>>> > including the contexts.
>>> >
>>> > I know manual parsing is a pain, but anyway, just wanted to
>>> throw
>>> this out,
>>> > maybe somebody has a good suggestion.
>>> >
>>> > Fabian
>>> > --
>>> > Fabian Lange | Performance Expert
>>> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>>> >
>>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>>> Deutschland
>>> >
>>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>>> Wuppertal
>>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>>> Jürgen
>>> Schütz
>>> >
>>>
>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>>
>>> Email: gnodet@redhat.com <ma...@redhat.com>
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Removal of JaxBUtil ?
Posted by Fabian Lange <fa...@codecentric.de>.
I cannot really tell.
Whatever XML stream or Document parser we would use, it also would load new
classes and require some time to initialize.
JAXB is however known to be the most inefficient in that regard. On the
other hand it offers the most convenience because you get these nice mapped
POJOs.
Felix SCR does it manually as far as I can see:
https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
Felix IPojo uses sax:
https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
Felix metatype uses xmlpullparser:
https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java
None of Felix uses jaxb.
Maybe its worth giving xmlpullparser a shot. The code of metatype looks
straigtforward, and the embedded classes are minimal.
Fabian
On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Fabian,
>
> interesting fact indeed. What alternate do you propose ?
>
> Regards
> JB
>
> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>
>> Hey,
>> I have new intel on this. A colleague generated a flame graph.
>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>> parsing.
>>
>> It is about 25% of the overall startup time just to boot up the jaxb
>> infrastructure.
>>
>> Fabian
>>
>>
>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>> fabian.lange@codecentric.de <ma...@codecentric.de>> wrote:
>>
>> Thanks, good hint.
>> For those inclined to understand my request, attached is the output of
>> -XX:+TraceClassLoading
>>
>> Using the xml binding feature approximately loads 800 classes (which
>> represent about 5MB memory)
>>
>> I haven't checked alternatives to the jaxb. And I am aware that this
>> is a
>> more esoteric requirement to reduce footprint.
>>
>> However, I am sure if this would not be from the JDK, nobody would
>> pull in a
>> 5MB dependency to parse a single xml file.
>>
>> Fabian
>>
>>
>> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <gnodet@apache.org
>> <ma...@apache.org>> wrote:
>>
>> Note that on older branches, the feature repositories are still
>> parsed
>> using DOM
>> https://github.com/apache/karaf/blob/karaf-2.x/features/core
>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>> <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>
>> The xml is now also written, that may be the reason why we
>> switched.
>>
>> 2016-07-14 23:11 GMT+02:00 Fabian Lange <
>> fabian.lange@codecentric.de
>> <ma...@codecentric.de>>:
>>
>> > Hi,
>> >
>> > i am looking into ways to trim down Karaf. I notices that
>> Karaf uses JaxB
>> > to parse features.xml - However this is the only application
>> of JaxB.
>> >
>> > Could somebody more involved help me to figure out if it is
>> worth to
>> > replace it with manual marshalling? I assume other xmls are
>> parsed
>> > differently?
>> > Advantage would be that the whole jaxb infrastructure could be
>> avoided,
>> > including the contexts.
>> >
>> > I know manual parsing is a pain, but anyway, just wanted to
>> throw
>> this out,
>> > maybe somebody has a good suggestion.
>> >
>> > Fabian
>> > --
>> > Fabian Lange | Performance Expert
>> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>> >
>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>> Deutschland
>> >
>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>> Wuppertal
>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>> Jürgen
>> Schütz
>> >
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com <ma...@redhat.com>
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Removal of JaxBUtil ?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Fabian,
interesting fact indeed. What alternate do you propose ?
Regards
JB
On 08/09/2017 10:46 AM, Fabian Lange wrote:
> Hey,
> I have new intel on this. A colleague generated a flame graph.
> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB parsing.
>
> It is about 25% of the overall startup time just to boot up the jaxb infrastructure.
>
> Fabian
>
>
> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <fabian.lange@codecentric.de
> <ma...@codecentric.de>> wrote:
>
> Thanks, good hint.
> For those inclined to understand my request, attached is the output of
> -XX:+TraceClassLoading
>
> Using the xml binding feature approximately loads 800 classes (which
> represent about 5MB memory)
>
> I haven't checked alternatives to the jaxb. And I am aware that this is a
> more esoteric requirement to reduce footprint.
>
> However, I am sure if this would not be from the JDK, nobody would pull in a
> 5MB dependency to parse a single xml file.
>
> Fabian
>
>
> On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <gnodet@apache.org
> <ma...@apache.org>> wrote:
>
> Note that on older branches, the feature repositories are still parsed
> using DOM
> https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
> <https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>
> The xml is now also written, that may be the reason why we switched.
>
> 2016-07-14 23:11 GMT+02:00 Fabian Lange <fabian.lange@codecentric.de
> <ma...@codecentric.de>>:
>
> > Hi,
> >
> > i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> > to parse features.xml - However this is the only application of JaxB.
> >
> > Could somebody more involved help me to figure out if it is worth to
> > replace it with manual marshalling? I assume other xmls are parsed
> > differently?
> > Advantage would be that the whole jaxb infrastructure could be avoided,
> > including the contexts.
> >
> > I know manual parsing is a pain, but anyway, just wanted to throw
> this out,
> > maybe somebody has a good suggestion.
> >
> > Fabian
> > --
> > Fabian Lange | Performance Expert
> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
> >
> > codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
> >
> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
> Schütz
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com <ma...@redhat.com>
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com