Re: [xmlvm-users] OneJar and XMLVM

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

2010/9/18 Panayotis Katsaloulis <pan...@pa...>

> On 18 Σεπ 2010, at 2:25 μ.μ., Sascha Haeberling wrote:
> > I invested quite a lot of time to improve the internal structures of
> XMLVM, mainly the UniversalFile API, that makes it now very easy to handle
> the situation where resources are located either inside or outside the
> One-JAR.
>
> Exactly that's my point.
> I have seen in the source code that you have started to use  UniversalFile
> which handles this situation, which from my point of view is a bad approach.
> And before all this effort grows and be too big and/or important to abandon
> it, I wanted to present these problems and why (since some time ago) I am
> against the one-jar approach.
>

I disagree that this is a bad approach. The API makes it quite simple and
totally transparent to handle both situations well. I am not planning to
abandon it at all. It is now a well documented powerful API that is a core
part of XMLVM.


>
>
> > You said that things grow big. That is natural and as Joshua pointed out,
> this is not a problem nowadays. Of course, if the One-Jar would become
> hundreds of MBs big, that would be too much. But right now it doesn't feel
> too big to download.
> > One more note on size: Of course things will get added, but we will
> hopefully be able to significantly reduce the size of it soon. The OpenJDK
> libs included contain too much stuff we will never need. Once we figured out
> what is "junk", we will cut it out and we should be able to get rid of many
> MBs easily.
>
> Still, the performance loss in terms of speed will always be there.
> And as you said exactly, there is a lot of developer effort to support
> something that (in my point of view) is not a good idea any more. Space is
> one issue only. Anyway, even space is important, I don't like bloated
> software just because we can do it. I prefer more elegant solutions, without
> sacrificing ease of use.
>

Of course software shouldn't be bloated. But if many of the bytes that are
inside the JAR are needed, the other way would be to download these
dependencies separately. So having the One-JAR is much nicer.


>
>
> > The other argument you made is speed. Panayotis, you wrote a long e-mail
> (which you ponted out yourself), but you failed to provide data: What I need
> to to know are hard facts. Provide data about what takes how long and why
> this is a problem, and how fast it would be in another case. THEN we we have
> foundation to talk about and THEN we can maybe find other solutions as well.
> > For example: I don't know how the OneJAR mechanism exactly does its work,
> but I agree with you in that it seams silly to extract parts of the OneJAR
> that are not needed. E.g. when you just want to cross-compile a bunch of
> files, you don't need to extract certain libs every time. However, with ZIP
> files you can extract certain parts only, so it would make sense to have it
> extract only the needed parts.
> > Another way to solve this is to extract things on first run and to cache
> it on the disk to improve speed when executed again.
> > But again, for me what matters are numbers, and not assumptions. If you
> can provide measurable numbers about what's slow, why it is bad and how fast
> it could be, then we can talk concrete steps in improving the situation.
>
>
> I said in a previous post how to get these numbers you are talking about,
> but, anyway, here they are.
> If you want numbers, numbers you will have:
>
> cd build/base/main ; time java -cp main.jar org.xmlvm.proc.NewMain
> 0.24 real         0.25 user         0.04 sys
>
> cd build/bin/ ; time java org.xmlvm.proc.NewMain
> 0.23 real         0.24 user         0.04 sys
>
> cd dist ; time java -jar xmlvm.jar
> 2.16 real         2.37 user         0.25 sys
>
>
> It's as you can see, an order of magnitude slower. Are these enough hard
> facts for you? If you run these scripts hundred times per day, in
> production, you will have the same feeling as I do.
>

Actually no. Of course just showing the help dialog is the worst situation.
But show me the numbers when compiling a whole project.

I don't think that extracting data from the OneJAR is a huge part in the
whole process. Believe me, I care about speed just as much as you do. Last
week I made some significant changes that speed up the compilation
significantly. I was able to save minutes. If the OneJAR only adds 2 seconds
to a cross-compilation, I would see it as rather insignificant. But of
course, if there are clever ways to make the OneJAR faster, I am always for
it,but I wouldn't abandon it.



>
> What actually surprises me is that the speed of using jars and files on
> disk takes exactly the  same time. It makes sense of course, since the time
> we loose to unzip something in memory will equal the time to access
> different files on disk.
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>