Labview 8.x.x Install Sizes

[brent99]

I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.

[jzoller]

QUOTE(brent99 @ Feb 22 2008, 12:21 PM)

I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.

Dead horse: yes.

Still true (and annoying): yes.

JZ

[crelf]

[jzoller]

In a more useful vein, here's Adam Kemp's reply on the same subject from Info-LabVIEW:

"It may be annoying, but it's not unheard of either. Most programs need

some kind of runtime code to work. Native applications need runtime DLLs

that happen to come with the OS, so you don't notice. Programs written

in other languages like VB need runtime DLLs that happen to be very

small. Then you have programs like Java and .Net which need bigger

runtime components. Java comes in around 10-20MB and .Net is about

20-30MB. Depending on your OS version you may or may not already have

these components installed, but that didn't use to be the case.

If you think about file size compared to the size of drives and typical

bandwidth for network connections, then LabVIEW is doing fine compared

to what Java users had to go through in the 1990s. The JRE took about 30

minutes (or more) to download back then, and it seemed like every

program written in Java came with a different version of the JRE.

Fortunately Java has settled down a bit since then, and people can

mostly get away with relying on the JRE pre-installed on most systems.

LabVIEW can't get away with that (it's probably not going to be

pre-installed on systems any time soon).

It's unfortunate, but realistically it's not very different from the

other software tools. We just don't have the benefit of coming

pre-installed like they do. Maybe some day. :)"

[brent99]

Yes, the "dead horse" posts are useful because its not just me, which was my question.

The point isn't that there is an RTE, but that the RTE grew so dramatically from 7.0 to 8.0 with the main feature being a project manager. WTF? (Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine)

Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

[crelf]

QUOTE(jzoller @ Feb 22 2008, 03:33 PM)

If you think about file size compared to the size of drives and typical bandwidth for network connections, then LabVIEW is doing fine compared to what Java users had to go through in the 1990s.

it's okay for the LabVIEW RTE to be huge because download speeds have increased? I can see where he's coming from, but that's a pretty weak link IMHO...

[Rolf Kalbermatter]

QUOTE(brent99 @ Feb 22 2008, 05:06 PM)

Yes, the "dead horse" posts are useful because its not just me, which was my question.

The point isn't that there is an RTE, but that the RTE grew so dramatically from 7.0 to 8.0 with the main feature being a project manager. WTF? (Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine)

The project management is specifically not part of the RTE. Almost anything editor related is NOT part of the RTE. The LabVIEW RTE got big because of many new features and also support libraries which could or could not be important for a specific application. The problem is to chose between easo of use: you just create an installer and everything will work normally or requiring the user to have a very detailed knowledge of what he really needs to select as subparts in a build. Many users are already overwhelmed by the choices of extra components to add to an installation in the 8.x Builder. Subdividing the RTE in one dozen or more sub packages wouldn't make that simpler for sure.

Whoever has created Windows Embedded projects knows probably what I'm talking about. There you have to decide what components you want to put in an installer and if you got it wrong the target system simply won't start, sometimes issuing a useful error message but quite often not.

QUOTE

Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

Well, the actual diagram (such as all the structures like loops, cases, etc as well as the actual wiring of data between nodes) is compiled into machine code of course but not every node is compiled into machine code on the fly and added into the VI itself.

Most little yellow nodes are in fact function calls into the LabVIEW kernel or RTE. Also there is a lot of code necessary to draw the front panel, schedule execution of all the VIs and many more things like support for interfacing to VISA, Bluetooth, TCP/IP, etc. These things do not get added into the executable itself as that would be both a huge task to prepare a linker system that could link these together properly for the specific target system into an executable as well as a waste of storage space since each executable would contain the same code over and over again.

Rolf Kalbermatter

[Ton Plomp]

QUOTE(rolfk @ Feb 23 2008, 10:23 AM)

The project management is specifically not part of the RTE. Almost anything editor related is NOT part of the RTE. The LabVIEW RTE got big because of many new features and also support libraries which could or could not be important for a specific application. The problem is to chose between easo of use: you just create an installer and everything will work normally or requiring the user to have a very detailed knowledge of what he really needs to select as subparts in a build. Many users are already overwhelmed by the choices of extra components to add to an installation in the 8.x Builder. Subdividing the RTE in one dozen or more sub packages wouldn't make that simpler for sure.

Whoever has created Windows Embedded projects knows probably what I'm talking about. There you have to decide what components you want to put in an installer and if you got it wrong the target system simply won't start, sometimes issuing a useful error message but quite often not.

Rolf Kalbermatter

The LabVIEW RTE installer is 32 23MB not that bad, a typical app I would mail to a client would just a few MB.

Ton

[Rolf Kalbermatter]

QUOTE(tcplomp @ Feb 23 2008, 04:38 AM)

The LabVIEW RTE installer is 32 MB not that bad, a typical app I would mail to a client would just a few MB.

Yes! If I send an executable to a client I add everything that the executable needs to run, except the runtime engine. I just add a link to the appropriate NI download page for the RTE and tell the client to install that.

That gives me usually ZIP archives of about 1MB up to 10MB depending on the project size.

Rolf Kalbermatter

[Yair]

QUOTE(brent99 @ Feb 23 2008, 12:06 AM)

Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it?

Don't tell anyone I told you this, but the reason that RTE is so big is that it has thousands of tiny programmers in it which convert the code to C.

QUOTE(crelf @ Feb 23 2008, 02:39 AM)

it's okay for the LabVIEW RTE to be huge because download speeds have increased? I can see where he's coming from, but that's a pretty weak link IMHO...

That's not exactly what he said. In addition to the actual reasons, he just said the situation of LV users today is better than what Java users had 10 years ago.

[crelf]

QUOTE(Yen @ Feb 24 2008, 04:03 PM)

That's not exactly what he said. In addition to the actual reasons, he just said the situation of LV users today is better than what Java users had 10 years ago.

You're right - it's not *exactly* what he said, but I don't think it's a large nor unreasonable extrapolation.

[Rolf Kalbermatter]

QUOTE(crelf @ Feb 24 2008, 06:47 PM)

You're right - it's not *exactly* what he said, but I don't think it's a large nor unreasonable extrapolation.

Not sure I can agree to that? When were you last able to put a Windows service pack or KB patch onto a Floppy disk? Or a Macintosh OS bugfix? Or Linux for that matter! Without a fast broadband access keeping up with the state of security fixes on all these systems is simply an impossible thing.

Ok you could also say without broadband access those security fixes aren't that important. But then maybe going with let's say LabVIEW 6.1 instead of 8.5 wouldn't be either.

Rolf Kalbermatter

[Aristos Queue]

QUOTE(brent99 @ Feb 22 2008, 04:06 PM)

(Ok you could blame the new OO support, but then give us the ability to opt-out since its not a heavily used feature, I imagine)

No, you can't blame OO. The OO code isn't in the real time engine yet. That's still in development. Many people have made this assumption. For that matter, the project isn't compiled into the runtime or realtime engines, so it isn't that either.

For reference, when the OO code does become part of realtime, we expect to add a couple of one or two K to the runtime engine size at most. This is still a ways in the future, but it is on the road map.

[Rolf Kalbermatter]

QUOTE(Aristos Queue @ Feb 25 2008, 10:40 AM)

No, you can't blame OO. The OO code isn't in the real time engine yet. That's still in development. Many people have made this assumption. For that matter, the project isn't compiled into the runtime or realtime engines, so it isn't that either.

For reference, when the OO code does become part of realtime, we expect to add a couple of one or two K to the runtime engine size at most. This is still a ways in the future, but it is on the road map.

Hmm, RTE can also be run-time engine. And there I would expect to have OO runtime support, otherwise you couldn't run executables that use OO. But I agree the runtime support for that won't be extereme in size.

A lot of what the run-time engine adds to the system are in fact secondary things such as multi language support for it's dialogs and runtime texts, Intel Math Kernal Library, Service Locator, Logos Sybsystem, etc. etc. Most of them not strictly necessary but using some seemingly harmless functionality could already depend on one or more of these.

Rolf Kalbermatter

[REM1]

QUOTE(rolfk @ Feb 25 2008, 12:56 PM)

Hmm, RTE can also be run-time engine. And there I would expect to have OO runtime support, otherwise you couldn't run executables that use OO. But I agree the runtime support for that won't be extereme in size.A lot of what the run-time engine adds to the system are in fact secondary things such as multi language support for it's dialogs and runtime texts, Intel Math Kernal Library, Service Locator, Logos Sybsystem, etc. etc. Most of them not strictly necessary but using some seemingly harmless functionality could already depend on one or more of these.Rolf Kalbermatter

I think the point that AQ was making is that while the desktop runtime engine is quite large, the RTOS runtime engine is significantly smaller.QUOTE(brent99 @ Feb 22 2008, 01:21 PM)

I apologize if I'm beating a dead horse here -- I'm not sure if and how often this has been brought up in the past -- but I'm kind of annoyed at how large the distribution file has become since Labview 7 because of the massive Labview 8 RTE. I used to be able to distribute a complex program at about 8MB or so. Now, even a simple program is taking like 50MB. Am I alone in this or do other people see this problem? You can email an 8MB program, but you have to serve up a 50MB program. It really limits distribution of a simple program to people who don't normally use Labview.

In 7.1, lvrt.dll was 5716 KB as opposed to 10577 KB in 8.5In 7.1, language resource files accounted for 0 as opposed to 30 MB in 8.58.5 also includes the browser plugin, project provider framework, DNCInterface, a PSP browser dll, and several other dlls who's function I do not know.

[crelf]

QUOTE(rolfk @ Feb 25 2008, 01:11 AM)

Not sure I can agree to that? When were you last able to put a Windows service pack or KB patch onto a Floppy disk?

You've missed my point entirely Rolf - I was trying to say that "just because you can, doesn't mean that you should". You shouldn't assume that everyone in your target user base has access to a broadband connection. At least, not yet

[PJM_labview]

One of the thing that could bear some improvements is the error message one get when trying to run a software that does not have the LV runtime install.

It goes more or less like this: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please contact the vendor of "myexecutable.exe" to correct this problem.

This error is really not usefull to the user of the software (it is conceivable that they do not know what is LabVIEW).

If the message was more like: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please Click here to download an install it. This would be a lot more usefull.

Just my two cents

PJM

[crelf]

QUOTE(PJM_labview @ Feb 25 2008, 09:42 PM)

If the message was more like: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please Click here to download an install it. This would be a lot more usefull.

I agree that would be useful, but I'd want this to be selectable. We build turn-key test systems, so, usually, if one of my users gets that error, then they've screwed something up completely. I'd prefer it if they contacted the vendor (me), lest they've done something catastophic to the system.

[Rolf Kalbermatter]

QUOTE(crelf @ Feb 25 2008, 06:53 PM)

You've missed my point entirely Rolf - I was trying to say that "just because you can, doesn't mean that you should". You shouldn't assume that everyone in your target user base has access to a broadband connection. At least, not yet

But they didn't say they did it because they can. They said they did not think it was a bad thing since in nowadays days you do not use the same means to distribute applications as you did back in 1991. I'm sure the LabVIEW developers do not add software components to the runtime system just to bloat the whole thing. They do that because it adds some functionality somwhere and since modern distribution systems allow such sizes more easily they go rather for the added functionality than spending months and months to try to squezze another few MBs out of it or create a complicated and cumbersome user configurable component based runtime installer.

Yes the components are actually there but the user interface to configure them would be a bit complicated for sure and many of the components not even we could decide if they are needed or not, until you happen to run the application on the target system in question and notice strange artefacts or errors somewhere.

There were at least for 8.2 already two different runtime installers. One containing everything and wheigting in at around 89MB and the other containing only the actual runtime and weighting in at 24MB. And many users wondered why they can't run their application when using the smaller one only to find out that the bigger one worked. That little Mean function in there unfortunately wanted to see the MKL installed and that was one part among many others that was not installed by the smaller installer.

NI specifically said the small one was for Web Browser use only (Front Panel inside a web browser) and that means anything the Front Panel needs is there but all the rest that a diagram function could use is not there if it isn't contained in the runtime engine DLL itself since the diagram is executed on the server anyhow. And many users got upset that there was a smaller installer.

So I think we can ask for more fine grained selection of runtime engine components but it won't make things really easier and therefore won't be used much. Also as you can see from the 8.2 installer, much smaller than 20 MB won't be possible anyhow (you could still shave of the non-English or whatever you want language resources) and that is still not a size that you normally want to email. Even the most minimalistic LabVIEW 7.1 runtime engine that I sometimes copy together with my executable into the same directory was at least 10MB in size and then you couldn't do 3D controls, or Advanced Analysis Library or many more things. Good enough for a small Autostart executable on a CD but not really useful for a normal LabVIEW application.

Rolf Kalbermatter

[brent99]

QUOTE(REM1 @ Feb 25 2008, 11:47 AM)

I think the point that AQ was making is that while the desktop runtime engine is quite large, the RTOS runtime engine is significantly smaller.In 7.1, lvrt.dll was 5716 KB as opposed to 10577 KB in 8.5In 7.1, language resource files accounted for 0 as opposed to 30 MB in 8.58.5 also includes the browser plugin, project provider framework, DNCInterface, a PSP browser dll, and several other dlls who's function I do not know.

There are other languages besides english?? <sik> Well, there you go, 30MB for language support is a pretty big deal. And I think the browser plugin is somewhat unnecessary, based on my own personal experience having just installed that yesterday.

The POINT is that you can't make "hello world" and distribute it to Joe Public (who doesn't have labview 99% of the time) under 10GB anymore, which is not good. And I use 10GB because MOST public email systems will not handle mail files larger than 10GB. In fact, most barely handle ones near 10GB if you are lucky enough to get an attachment to upload properly (works in hotmail, not much else).

Looking at Labview as a great way to write simple programs, this is a problem. If you are looking at it for a full heavy weight corporate application, I don't think its such a problem but not everyone looks at labview that way (ducks).

[Ton Plomp]

QUOTE(brent99 @ Mar 3 2008, 07:58 PM)

The POINT is that you can't make "hello world" and distribute it to Joe Public (who doesn't have labview 99% of the time) under 10GB anymore, which is not good. And I use 10GB because MOST public email systems will not handle mail files larger than 10GB.

I don't think its such a problem but not everyone looks at labview that way (ducks).

The language part is not 30 MB, I have never looked into it but some countries/industries/people really rely on own-language apps.

I hope you mean 10 MB, and otherwise you should get an FTP server (finally our company is thinking about such a feature after 3 years of complaining and throwing things through the office

But I don't expect a 3k€ package to write simple programs!

I expect such an expensive package to solve difficult problems in a simple way.

Ton

[brent99]

QUOTE(PJM_labview @ Feb 25 2008, 06:42 PM)

One of the thing that could bear some improvements is the error message one get when trying to run a software that does not have the LV runtime install.

It goes more or less like this: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please contact the vendor of "myexecutable.exe" to correct this problem.

This error is really not usefull to the user of the software (it is conceivable that they do not know what is LabVIEW).

If the message was more like: "myexecutable.exe" requires version 8.5 (or compatible) of the LabVIEW Run-Time Engine. Please Click here to download an install it. This would be a lot more usefull.

Just my two cents

PJM

Or put in the context of my issue....

This would solve the "problem" if you could create an installer that installs via the web if the RT X.X runtime engine has not yet been installed!!!!

Great idea.

[crelf]

QUOTE(brent99 @ Mar 3 2008, 01:58 PM)

If you are looking at it for a full heavy weight corporate application, I don't think its such a problem but not everyone looks at labview that way (ducks).

Not everyone, but I'd suggest that the vast majority does.

[PJM_labview]

Absolutely! I could not agree more,

PJM

[crelf]

QUOTE(PJM_labview @ Mar 3 2008, 02:43 PM)

Absolutely! I could not agree more,

To what?