Hi Rémi,

On 07/11/2011 03:11 AM, Rémi Denis-Courmont wrote:
> On Friday 08 July 2011 21:23:34 ext Denis Kenzior, you wrote:
>> Hi Oleg,
>>
>> <snip>
>>
>>> +static int gprs_provision(const char *mcc, const char *mnc,
>>> +				const char *spn,
>>> +				struct ofono_gprs_provision_data **settings,
>>> +				int *count)
>>> +{
>>> +	int i;
>>> +	struct parser_data *data;
>>> +	*settings = NULL;
>>> +
>>> +	DBG("Provisioning for MCC %s, MNC %s, SPN '%s'",
>>> +			mcc, mnc, spn);
>>> +
>>> +	data = g_try_new0(struct parser_data, 1);
>>> +	if (data == NULL)
>>> +		return -ENOMEM;
>>> +
>>> +	lookup_apn(mcc, mnc, NULL, data);
>>
>> What I wonder is what is the overhead of the XML parser right now (e.g.
>> how long it takes on reasonable embedded hardware).  If this takes a
>> while, then it might be better to pre-parse the mobile-provider-info db
>> during plugin initialization and not every time gprs_provision is
>> called.  Otherwise we run the risk of hanging the daemon while the
>> provision settings are being looked up.
> 
> Provisioning should be a fairly rare occurence. Preparsing the table into 
> memory might be a waste of both CPU and memory in the common circumstances...
> 

I do agree here, but it is the lesser evil than hanging the daemon for x
seconds.  However, first I'd like to know what the parsing speed is...

> If you suspect the parser is slow (I doubt it, but I have not checked), then 
> it might be better to just do it in a separate thread in the rare cases that 
> you actually do need the data.
> 

Separate thread will not help since the function has to return
synchronously.  I doubt the overhead of storing this information will be
big, but if it is then we can play other tricks like pre-parsing the db
into a quick-look-up file format at start-up, etc.

Regards,
-Denis