In fact it's a good pratice to always use B_NORMAL_PRIORITY and only
tune thread priority *if* you encounter performance issue.
As in your case the performance is far more IO limited than schedule,
there is no point here.
Better redesign it to cache some data or load larger bit of data at
once, or if it's not IO speed the bottleneck but the data processing
part, split the task in order to parallelize reading, processing and
writing subtask.
Last but not least, as your app already comes with the data file(s)
needed to *install* data processed from these initial dataset, can't you
optimize the initial dataset in order to reduce the amount of
"install"-specific processing part?
Bye,
Philippe.
