Hi,
I have been dealing with very large XML files myself in the past but
never really had performance issues when following some basic guide
lines and best practices.
In your case, I could imagine of your performance problem being a
combination of something like the following:
1. if dropping multiple JAR's still all are processed sequentially
2. the whole contents of the XML file is regenerated from scratch each time
3. to regenerate the XML file, other file data is required, resulting in
additional unnecessary I/O
This is just some idea, without having any clue about the bndtools
internals. So, it may just be useless.
But probably, it gives you some idea of where to look for yourself in
order to help improving the situation or at least identifying the
biggest bottlenecks.
Speaking of which, the first questions would be:
A) Is the processing I/O bound or CPU bound?
B) Is the processing consuming only one CPU core or multiple?
c) Is network traffic involved?
Cheers,
Ancoron
On 20/06/15 14:37, Ergüder Bekrek wrote:
> Greetings to everyone!
>
> Every time that I want to remove bundle from the local repo XML it takes
> to much time.
> I think it is a terrible design choice to persist all the bundle we
> drag&drop inside one giant XML.
>
> my file is now 9.3 MB and Bndtools is freezing my Eclipse Environment
> all the time when I drag & drop
> let say 20 jars at once.
>
> I think a method which will improve the speed of Bndtools is to make one
> xml folder which contains independant xml files for
> each bundle.
>
> It will also make it more easy to manually remove bundles by deleting
> the respective xmls instead
> of searching them in a 10 MB xml files.
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
