Big performance issue while downloading object to file on local machine (Windows xp)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start ZSAPLINK
2. Click on "Slinkee" tabstrip
3. Select "Export Object to Slinkee" checkbox, choose "FUGR" and function 
group name which contains 1 function with 5000 lines
4. Execute -> system hang

What is the expected output? What do you see instead?
System hang, and low memory warning

What version of SAP are you using?
SAP_ABA Release / Level: 700 / SP8, windows xp/minisap
SAP_BASIS Release / Level: same

What version of SAPlink are you using:
0.1.3

Please provide any additional information below.
Performance issue in program ZSAPLINK, subroutine PUTONMACHINE:
    split xmlString at CL_ABAP_CHAR_UTILITIES=>NEWLINE
    into table tempTable_char.
I guess that, as internal table tempTable_char is made of rows with 65535 
characters each, it consumes up to 5000 * 65535 (>300 MB) in memory -> 
causes paging.

Please find attached my solution.

Original issue reported on code.google.com by sandra.r...@gmail.com on 6 May 2007 at 4:44

Attachments:

• putOnMachine.txt

[GoogleCodeExporter]

Original comment by ewherrm...@gmail.com on 8 May 2007 at 12:57

• Added labels: Points-25

[GoogleCodeExporter]

Original comment by ewherrm...@gmail.com on 28 Jul 2007 at 5:47

• Changed state: Accepted

[GoogleCodeExporter]

I had the same problems where I attempted to download 400 objects from a 
transport request.  It blew SAP 
out of the water even though it had 6GB allocated to it.

Just looked at the patch submitted and wondering why we have to add all the 
extra code to convert the 
xmlString to binary before saving it.

I changed line "data: temptable_char type table of t_char" to  "data: 
temptable_char type table of string" and 
this works perfectly.  it would actually reduce the number of lines of code by 
3 and works on an old 6.20 
system I have access to.

If we can agree on a solution I will raise a patch.

Ed

Original comment by edwardme...@gmail.com on 4 Sep 2007 at 4:33

[GoogleCodeExporter]

Sandra,
Thanks for the solution.  

Ed,
I can't remember the situation, but there was a reason (I think) why we didn't 
choose to use a data type String.

I'll take a look next week...sorry for the delay.
We'll have some concensus soon.

Quack 

Original comment by rquacken...@gmail.com on 2 Oct 2007 at 2:52

[GoogleCodeExporter]

Hi Ryan,

Eddie seemed to think that it might be something to do with Unicode systems, 
although he was unsure. I think 
that we ought to try string again and test the outcome.  I have access to a 
couple of Unicode systems if we need 
them for testing.

Ed

Original comment by edwardme...@gmail.com on 2 Oct 2007 at 2:15

[GoogleCodeExporter]

I confirm that the simple solution with "data: temptable_char type table of 
string" 
works on a unicode system.

Okay, rquackenboss, I recognize that your solution is better than mine (yours = 
1 
line changed ; mine = 100 lines of code), but I like art ;-)

Original comment by sandra.r...@gmail.com on 16 Nov 2007 at 10:20

[GoogleCodeExporter]

Sandra,

Thanks for testing that change, and I'm glad it worked.  Did you test it on 
various 
versions of the ABAP stack; 6.2, 6.4 and 7.0?  The next test is to make sure it 
didn't break the original fix.  The reason the code was changed in the first 
place 
was because when a patch was submitted, the subversion repository couldn't 
handle 
the binary representation of the file.  The change to table_of_strings should 
not 
have the same effect, but I just want to make sure.  Please create a patch on 
Unicode, and non-Unicode systems with the modified code.  The patch can be very 
simple for the test.  Please read this blog if you're not sure how to create a 
patch.
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4965

Thanks,  

Quack

Original comment by rquacken...@gmail.com on 18 Nov 2007 at 1:48

[GoogleCodeExporter]

It will take me a little time to understand what is "subversion", and what I 
have to 
do exactly. What I can surely do is to test on a 620 non-unicode system.

Original comment by sandra.r...@gmail.com on 20 Nov 2007 at 11:44

[GoogleCodeExporter]

Test with 6.20 NON-unicode. At the beginning, I couldn't use 0.1.3 on 6.20 
because
ZSAPLINK program couldn't be activated, I created issue 92. I then saw in the 
project
discussions that someone had seen the problem and corrected it and proposed a 
patch
file. It worked for me THEN I could do the test of the correction of issue 68, 
which
was okay.

Original comment by sandra.r...@gmail.com on 24 Nov 2007 at 11:45

Attachments:

• PROG_ZSAPLINK_68.patch

[GoogleCodeExporter]

Test with 7.0 unicode is okay too.

Original comment by sandra.r...@gmail.com on 14 Dec 2007 at 7:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by mepmarc...@gmail.com on 28 Oct 2008 at 12:58

• Changed state: Fixed
• Removed labels: Fixed