| ddmitrie wrote: |
| was that text too long then? |
Let me make this simple. Here's an example to illustrate:
//Lets create an array of objects that contain a small string of text.
for($i=0;$i<=300;$i++){
$str = "Now is the time for all good men to come to the aid of their country";
$object = "object".$i;
$arry[$i]->$object = $str;
}
//Now serialize the array and produce a long string with the serialize() function.
$hover_over_me_to_see_your_cpu_max_at_100_percent = serialize($arry);
//set a break point below here and ^ inspect the variable.
//It causes my CPU to hang for a few moments. Does it for you?
|
If you copy/paste the serialized string into notepad -- you'll see that it is one long uninterrupted string -- without any carriage returns or line feeds. I believe that your tool-tip is trying to best parse the string for display by searching for "lines of text" but not taking into consideration the uninterrupted length of the string.
In contrast, the tool-tip in the Locals and Globals window handles the string gracefully. However, the local/global tool-tip does not display multiple lines of text -- so it appears to measure the length of the string (the sharp, brief 50% jump in the cpu) and then cuts it off to a manageable length for display. Whereas the tool-tip in the code window appears to be measuring the cumulative height of the lines of text -- expecting there to be some \r\n 's to assist.
I've been writing a managed .Net text editor utilizing the Ms Uniscribe library and have witnessed this behavior in my own code. At some point you have to stop rendering text that is out of view -- otherwise you'll get performance issues like this one.
BTW: I am a happy new customer. I couldn't pass up the fantastic sale you had a few weeks ago! It feels great knowing my trial isn't going to expire soon!
RSS2 Feed
The problem stems from using the serialize() function on a large array containing text from a parsed XML file.
Posted: Fri Aug 11, 2006 12:24 am
