NumericArrayResize CIN function bug (feature)

[Tomi_Maila]

---

@rolfk wrote:

As to developing Toolkits for LabVIEW you will quite soon find out, that this is a market you can't really live from.
A lot do want to get additional functions for free, expect outstanding documentation nevertheless, and consequently a perfect one for something they buy and will usually prefer a solution from NI before any other unless it is very outstanding and special. And then you should not forget about all those with the "Not invented here" syndrome.

So you will be spending lots of time for something you can not easily get enough money with to pay your development costs not to speak about your support. That is not so much NIs fault (well you could ask them not to sell any Toolkits to increase your chances) but just how things are.

---

It sounds like you have lots of experiense in this field. I also assume you are prefectly right.

To be honest, I'd like to see G as an open programming language so that the G standard would be developed independetly and LabVIEW would be one leading implementation of G. This would greatly enlarge the G community and would propably also increase the revenue of NI as the major G development environment provider. This would also bring more and perhaps better planned features into G.

Graphical programming is a great tool for software development. It has many benefits over conventional programming languages (I assume you Rolf can at least agree on this). It's a pity that there are not really greate general purpose graphical programmin languages out there. LabVIEW G is the best one can get and it's developed more and more towards a data aquisition and manipulation language and not general purpose programmin language.

[rolfk]

---

@Tomi M wrote:

It sounds like you have lots of experiense in this field. I also assume you are prefectly right.

To be honest, I'd like to see G as an open programming language so that the G standard would be developed independetly and LabVIEW would be one leading implementation of G. This would greatly enlarge the G community and would propably also increase the revenue of NI as the major G development environment provider. This would also bring more and perhaps better planned features into G.

Graphical programming is a great tool for software development. It has many benefits over conventional programming languages (I assume you Rolf can at least agree on this). It's a pity that there are not really greate general purpose graphical programmin languages out there. LabVIEW G is the best one can get and it's developed more and more towards a data aquisition and manipulation language and not general purpose programmin language.

---

You should not forget that LabVIEW has been in the past not really a product to make money with (and there is a good chance that it didn't do that in a big way until yet) but to promote hardware sales of NI products. And this has worked to the best of NI's advantage. In view of this an international standardization of the LabVIEW language (G is already taken so don't use that) is not something likely to happen very soon.

I do agree that LabVIEW is probably the best graphical programming environment so far that I have seen. Others have tried to come up with something similar, but they were mostly to simple in the design and accordingly clumsy in its uses and very limited in their possibilities. And NI does have a "few" patents on key elements of LabVIEW and a legal departement that does not sleep, so it is not just about cloning LabVIEW 😉

Rolf Kalbermatter

Message Edited by rolfk on 07-25-2006 06:21 AM

[nasa2grlv]

This this is an other NumericArrayResize problem.

When your system is fairly large, as in using significant memory, does anybody else have the NumericArrayResize fail to allocate large arrays often? (5 million or so doubles).  I am using windows, so to counter act this i used calloc first and then freed that memory then used NumericArrayResize and didn't have a problem after that.  Thought I'd throw that out there.  Does any of that make sense?

[rolfk]

---

@nasa2grlv wrote:

This this is an other NumericArrayResize problem.

When your system is fairly large, as in using significant memory, does anybody else have the NumericArrayResize fail to allocate large arrays often? (5 million or so doubles).  I am using windows, so to counter act this i used calloc first and then freed that memory then used NumericArrayResize and didn't have a problem after that.  Thought I'd throw that out there.  Does any of that make sense?

---

Hmmm interesting! Seems the C runtime allocator for calloc() at least does a little more bookkeeping and memory collation than the one used by LabVIEW. Because the LabVIEW memory manager functions ultimately simply call malloc() and free() too. It could be also an issue about which C runtime library is really called. Your C code may be explicitedly or implicitedly linking to a newer version of the C runtime library than what LabVIEW uses. It all depends on the Visual C++ version used to create the according binary code, unless you start to fiddle with specific linker switches yourself. This does usually work fine for things like memory management bacause underneath the C runtime library relies on the Windows HeapAlloc() and friends APIs for that but it is a well known and catastrophic failure for things like C runtime file descriptors when shared between modules compiled with different compiler versions and hence using different runtime library versions. Those descriptors are implemented in the C runtime library itself (usually an index into a table of pointers and consequently the descriptor of one runtime library has absolutely no meaning to that of another one, eventhough the underlaying API used is also the WinAPI.

Microsoft tried to attack this in the past by using a generic runtime library wrapper that would resolve the calls to whatever the most modern runtime library was on the current system, but I guess problems with binary compatibility of the APIs especially for the C++ calls made them reconsider and currently it is still a bad idea to mix runtime libraries in an application when using APIs that have some form of C runtime implemented descriptors or handles, eventhough as a plugin developer (LabVIEW shared libraries are in fact some sort of LabVIEW plugins) you often have no control about the runtime library used by the host application.

[nasa2grlv]

Thanks for your feedback.  I am using VS2010 running LV2010.  I didn't have a memory issue on my windows 7 64 bit with 8GB of RAM machine, but when I tried to run on my windows xp 32 bit with 3 GB of RAM machine it had problems until I did the Calloc trick.  So, I am linking to C++ libraries associated with VS2010 sp1.  I am kind of a novice with using Labview, so my frustration level is pretty high with Labviews memory management and dealing with problems with a lot of Labviews built in functions' slowness when dealing with large arrays.  I had to rewrite functions like the Hilbert Transform, Cheby Window, etc for my signal processing application.  Clearly, Labview's versions of these functions can not handle arrays in the millions of element range.  Is there a place to submit my VIs that run about 1000x faster than Labview's version to NI?