The problem with the Chinese phone numbers.

[olegsklyarov72]

Hello everybody. I get some problems with en/86.php. This file is too big compare with others (4,8Mb).
So, I must spend big amount of valuable memory (almost 75Mb) when use geocoding for Chinese phone numbers. When I add necessary size of memory by ini_set (although it is not good) I anyway get problems with geocoding some numbers. For example I try use geocoding for 86-157-9662-1289.
Actualy there is no such number and I should get empty result, instead I get fatal error, because it is need even more memory. Why that, I don't no. Anybody knows how to resolve this problem with memory wasting? May be should split the file 86.php into smaller files. Please, help me.

[giggsey]

Yikes, that array contains ~145,800 items.

I'll have a look at a way of solving this.

[giggsey]

I've split up the Chinese prefix mapper (geolocation & carrier mapper) files into smaller files, which has greatly reduced the memory usage when testing your number on my local PC.

Once Google release a new version, it'll get tagged, but for the time being, you can test it by using dev-master.

Demo Code

<?php

$number = PhoneNumberUtil::getInstance()->parse("86-157-9662-1289", "CN");
$geocoder = PhoneNumberOfflineGeocoder::getInstance();

$startMemory = memory_get_usage();
$location = $geocoder->getDescriptionForNumber($number, "en");
$endMemory = memory_get_usage();

$memoryUsed = $endMemory - $startMemory;

Before

Memory usage: 27260968 bytes (27 MB)

find . -name "*.php" -type f -not -path "./vendor/*" | xargs wc -l|sort -rn|grep -v ' total$' | head -n 10

  145802 ./src/libphonenumber/geocoding/data/zh/86.php
  145802 ./src/libphonenumber/geocoding/data/en/86.php
    9473 ./src/libphonenumber/carrier/data/en/55.php
    5584 ./src/libphonenumber/geocoding/data/en/33.php
    5210 ./src/libphonenumber/geocoding/data/en/49.php
    3330 ./Tests/libphonenumber/Tests/core/PhoneNumberUtilTest.php
    3180 ./src/libphonenumber/PhoneNumberUtil.php
    2653 ./src/libphonenumber/geocoding/data/en/91.php
    2093 ./src/libphonenumber/geocoding/data/en/359.php
    2093 ./src/libphonenumber/geocoding/data/bg/359.php

After

Memory Usage: 38288 bytes (0.03MB)

find . -name "*.php" -type f -not -path "./vendor/*" | xargs wc -l|sort -rn|grep -v ' total$' | head -n 10

   51459 ./src/libphonenumber/geocoding/data/zh/8613.php
   51459 ./src/libphonenumber/geocoding/data/en/8613.php
   41858 ./src/libphonenumber/geocoding/data/zh/8618.php
   41858 ./src/libphonenumber/geocoding/data/en/8618.php
   41269 ./src/libphonenumber/geocoding/data/zh/8615.php
   41269 ./src/libphonenumber/geocoding/data/en/8615.php
    9473 ./src/libphonenumber/carrier/data/en/55.php
    6986 ./src/libphonenumber/geocoding/data/zh/8614.php
    6986 ./src/libphonenumber/geocoding/data/en/8614.php
    5584 ./src/libphonenumber/geocoding/data/en/33.php

[olegsklyarov72]

The problem with memory usage was solved. But another one appeared. When I use geocoding I receive only one result: China. That is all. There is no detalization as it was befor: no province, no city.
It seems, that we can not get information from splited files.

[giggsey]

Is it the same number as per the original report? If so, I tried that on
the demo before I started making changes, and it was only reporting "China"
then.

I just tried that number in Google's demo page, and that said "China" too.

The problem with memory usage was solved. But another one appeared. When I
use geocoding I receive only one result: China. That is all. There is no
detalization as it was befor: no province, no city.
It seems, that we can not get information from splited files.

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

[olegsklyarov72]

Yes, the original number does not description, so the answer China is correct. But I try many others, for
example: 86-150-3657-7264, 86-136-3323-3696, 86-131-2270-1411. They have detalization and previous version showed them. Now it does not work.
86-150-3657-7264 - Luoyang, Henan;
86-136-3323-3696 - Zhangjiakou, Hebei;

[giggsey]

Okay, I can see that's an issue.

I'll work on it today.

[giggsey]

Okay, I believe I've fixed that now.

[giggsey]

The tests are failing because it's now reporting a higher memory usage. This is because it's finding the files to load (and not finding an entry for your original number, but is for the second set of numbers).

Can you check to see if it's still causing you memory issues with the latest dev-master?

[olegsklyarov72]

Yes, the problem with memory return.
Allowed memory size of 36700160 bytes exhausted (tried to allocate 7864320 bytes).
It works perfectly with existing numbers and required extra memory for non-existing.

[olegsklyarov72]

I have the problem with existing number also.
86-131-2270-1411 - Shanghai. It required extra memory.
But for 86-150-3657-7264 - works good.

[olegsklyarov72]

I am testing with many combiantion of area codes and phone numbers. The problem only with area-code 130 - 139. These codes stored in 8613.php. By the way this is the bigest file(1.7Mb) and contains many items.

[giggsey]

We might have to store them with 5 digits instead of 4 then.

Just a note that the default memory_limit for PHP is 128M, and yours is set to 32M. ( http://php.net/manual/en/ini.core.php#ini.memory-limit ).

[olegsklyarov72]

Please, could you answer what do we do now? Is your recommendation of increasing memory_limit final? The resolving of this problem is very important for us.

[giggsey]

I'm looking at splitting up the files into the first 5 digits.

[giggsey]

Can you give it another try?

Both the original number, and 86-131-2270-1411 now geo-locate using less than 5MB of memory.

[olegsklyarov72]

It is working perfectly now. Thanks a lot. That is a good luck for us.

[giggsey]

Excellent.

Like I said in a previous comment, it'll be in a tagged release once Google release a new version upstream.