Eliminate Quick Drop's Initial Launch Delay

[Darren]

As much as I love Quick Drop, I don't love this:

This delay occurs because we have to load all the palette information in the background to be able to drop objects by name.  You can choose Tools > Options > Controls/Functions Palettes > Load palettes during launch to front-load this delay during LabVIEW launch, but (1) a lot of you don't really like the longer launch time much better and (2) a lot of users still don't know about this setting.

I'm sure there's a way to solve this problem and make Quick Drop instantly usable, but I don't know enough about the underlying palette code to get it done.  Solving this problem, by the way, could have positive side effects on LabVIEW launch time, palette search performance, and maybe some other areas as well.

[AristosQueue (NI)]

I am not sure there's a way to solve this problem. We either read the palette files or we don't. There's not much room in between. The bound is on the file disk access, as far as I could tell.

[Mads]

What if it saved a file with the list it used the last time, and loaded that as a preliminary list - and then just refreshed it in the background? Would that not virtually cut the time to availability to nil?

Sure, some of the entries might have changed and it will not have a 100% correct list until after it has rescanned the palettes, but in 99% of the cases it will work...and if there is a stale entry that the user launches before the refresh has eliminated it then he will get an error...The QL window could have a status bar that told the user that it was reloading, but you would still have access to the list as it was on the last load.

Message Edited by Mads on 10-16-2009 03:02 AM

[JackDunaway]

"The bound is on the file disk access, as far as I could tell" It takes 5 or more seconds for QD to load for me. My disk read access is a few dozen MB/sec. So, are all of the palettes 150MB+? If not, it sounds like there is some optimization that could be done on palette loading and processing.

[Mads]

Searching lots of palette files is much slower then the speed you can get when streaming data from a single file Jack,  that is why I think having one file with the last known list will be an effective way to populate the QL-list on the first open...

[Darren]

It's true that there is a *lot* of information that gets loaded when you load the palettes.  One of the ideas I had was that we could just load a "lite" set of palette information for Quick Drop.  All Quick Drop needs is the object names; it doesn't need palette names, object icons, heirarchical information, help file paths, or any of the other information that currently gets loaded when the palettes load.

-D

[AristosQueue (NI)]

A) All the desktop OSes do read-ahead caching for a single large file, but many small files create the bottle neck, no matter how small they are. In theory -- based on other parts of LV we've built -- building a single palette file would help the situation, possibly significantly.

B) But the palettes aren't a static thing. There are toolkits that have to install separate from LV. There are user files dropped into user.lib. There are palettes that are dynamically generated from library files that change when you have a new license file. There are things that become visible when passwords are entered and are hidden otherwise. There are directories that are sync'd dynamically. 

C) QD may only need a subset of the palette information, but given the disparate places that LV has to look to collect that information, I'm not sure we'd save much. For example, by the time we've taken the time to read the files names from a particular library, we might as well snag the icon -- it's only a few bytes and we have the file open at that time. 

D) QD also has the same issue as the palettes of needing to have different stuff in it depending upon which Application Instance the user is working in. The FPGA palettes are different from the RT palettes are different from the Desktop palettes. And it wouldn't surprise me if there's other targets with specializations, too. 

[For the record, I'm not trying to be a wet blanket here... I'd love to see palette loading and QD load faster. I'm just highlighting the problems to make sure that any brainstorming people do takes all the requirements into account.]

[Darren]

---

Aristos Queue wrote:

...I'd love to see palette loading and QD load faster...

---

Then kudo my idea!  😛

[AristosQueue (NI)]

Not until I hear a feasible plan for doing it. I'd kudos "Sort 1D Array should run in O(n) time" too if there wasn't a hard proof that sorting cannot ever be done faster than O(n * log(n)).

This is an idea that seems likely to require changes not just in how the behind the scenes are implemented  but in how the feature is used and interacted with. If it were just a behind the scenes thing, I'd vote for it, but I might be more comfortable with the current slowness if the tradeoffs are particularly bad (in my subjective judgement). So until I know what the tradeoffs are, I'll hold off kudos.

We all have different standards for when to kudos an idea. This is one of my standards.

Message Edited by Aristos Queue on 10-16-2009 12:58 PM

[Darren]

---

Aristos Queue wrote:

Not until I hear a feasible plan for doing it.

---

Last I checked, we didn't require customers (or internal users) to submit design documents or prototypes demonstrating the feasibility of the ideas they submit on the Idea Exchange.  I'd have to go back to the thread to double-check, but for the most popular idea in this Exchange (New Boolean Constant Design), I'm pretty sure Christian did not submit resource and mutation code snippets along with his idea.  😉

Joking aside, I did propose a possible solution (harvesting a "lite" set of palette info).  Another solution proposed by one of our more performance-minded colleagues in R&D is a static palette configuration on disk that doesn't need to be parsed by LabVIEW to check for changes, but instead gets updated by installers that place new items in the palettes.

It's my understanding that the purpose of the Idea Exchange is to gauge LabVIEW community interest in an idea.  If you're interested in eliminating the Quick Drop launch delay, kudo this idea.  If the idea does eventually bubble up, we can start brainstorming solutions.  We may very well decide that there is no good solution and reject the idea.  But I don't think that type of brainstorming and feasibility analysis is supposed to happen here.

[AristosQueue (NI)]

> Last I checked, we didn't require customers (or internal users) to

> submit design documents or prototypes demonstrating the feasibility

> of the ideas they submit on the Idea Exchange.

True. But if I don't kudos an idea, it may very well be that I don't think it is worth spending research time on because I don't think we'll succeed in doing it. I might be wrong. It might be doable.  But is the probability of failure on project A greater thant the probability of success on project B? To my mind, on this idea, given current knowledge, yes. There are other things I want much more and for speculative development, I'd rather those get attention.

I'm one lone vote among many. I've only kudos'd 6 of the top 10 ideas. But those other 4 ideas will probably get kicked around even without my vote. Gather enough people who think this should be a LV priority and it too will get attention.