I write here to report a bug I had with Rkward, using bioconductor package lumiHumanV1 to annotate an illumina array with GO categories
When I run the lines given in the lumiHumanV1GO help file, I get an extraordinary long computation time (I let rkward running for more than 24 hours before I decided to stop it). when running the same code directly from the R console everything works perfectly it runs in only a few minutes.
I guess this comes from a bug from Rkward.
For any other task, rkward works fine on my computer
this might not be thee right place for bug report, if so could someone tell me where I should write ?
Maxime
PS: the code that caused rkward to crash...
# Convert to a list
xx <- as.list(lumiHumanV1GO)
# Remove all the NAs
xx <- xx[!is.na(xx)]
if(length(xx) > 0){
# Try the firest one
got <- xx[[1]]
got[[1]][["GOID"]]
got[[1]][["Ontology"]]
got[[1]][["Evidence"]]
}
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RKWard has performance issues when dealing with datasets containing many (tens of thousands) items (or sub-items, such as elements in a list/environment). GO is one of those packages, and I guess lumiHumanV1 is another. Frankly, I'm rather surprised, you don't see the issue directly when loading lumiHumanV1?
Unfortunately this is a problem of the current design and not easily solved, though at least some partial progress has been made. If you were using a version of RKWard prior to 0.4.8, upgrading to 0.4.8 will improve the situation somewhat (but probably not enough to be useful).
Thank you for your help, it's obviously the same problem that happens when using GO.
But the issue only appears when I try to use the lumiHumanV1GO object, not during the loading.
I use Rkward 0.4.7a with R.2.5.0 so this might be part of the problem, but for the moment I guess, I'll just keep on working directly with R and leave Rkward for tasks that do not involve Gene Ontologies...
Regards
Maxime
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, after installing lumiHumanV1 I can see why it does not fail while loading. This is because all the objects that cause the problem in lumiHumanV1GO are inside another environment, which RKWard will not investigate by default. You could - theoretically - avoid the hangup by making sure the large list never exists in a place where RKWard would see it, e.g. by wrapping a "local({...})" around the code in question. Of course this would only make sense, if the end result of your computation is a more managable dataset, that you can then assign/return to globalenv(). (Generally objects with many rows are fine (e.g. data.frame's), only large lists / environments are a problem).
So, indeed, I guess for now the only viable solution is to use plain R for such tasks. I'll keep the problem in mind, and I have some basic ideas on how to fix this, but as mentionend, this is going to take some time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I write here to report a bug I had with Rkward, using bioconductor package lumiHumanV1 to annotate an illumina array with GO categories
When I run the lines given in the lumiHumanV1GO help file, I get an extraordinary long computation time (I let rkward running for more than 24 hours before I decided to stop it). when running the same code directly from the R console everything works perfectly it runs in only a few minutes.
I guess this comes from a bug from Rkward.
For any other task, rkward works fine on my computer
this might not be thee right place for bug report, if so could someone tell me where I should write ?
Maxime
PS: the code that caused rkward to crash...
# Convert to a list
xx <- as.list(lumiHumanV1GO)
# Remove all the NAs
xx <- xx[!is.na(xx)]
if(length(xx) > 0){
# Try the firest one
got <- xx[[1]]
got[[1]][["GOID"]]
got[[1]][["Ontology"]]
got[[1]][["Evidence"]]
}
RKWard has performance issues when dealing with datasets containing many (tens of thousands) items (or sub-items, such as elements in a list/environment). GO is one of those packages, and I guess lumiHumanV1 is another. Frankly, I'm rather surprised, you don't see the issue directly when loading lumiHumanV1?
Unfortunately this is a problem of the current design and not easily solved, though at least some partial progress has been made. If you were using a version of RKWard prior to 0.4.8, upgrading to 0.4.8 will improve the situation somewhat (but probably not enough to be useful).
There is a bug-tracker at https://sourceforge.net/tracker/?group_id=50231&atid=459007 . You can also write about such problems to the rkward-devel mailing list (prior subscription recommended, as this makes spam control easier for us): https://lists.sourceforge.net/lists/listinfo/rkward-devel .
Regards
Thomas
Thank you for your help, it's obviously the same problem that happens when using GO.
But the issue only appears when I try to use the lumiHumanV1GO object, not during the loading.
I use Rkward 0.4.7a with R.2.5.0 so this might be part of the problem, but for the moment I guess, I'll just keep on working directly with R and leave Rkward for tasks that do not involve Gene Ontologies...
Regards
Maxime
Yes, after installing lumiHumanV1 I can see why it does not fail while loading. This is because all the objects that cause the problem in lumiHumanV1GO are inside another environment, which RKWard will not investigate by default. You could - theoretically - avoid the hangup by making sure the large list never exists in a place where RKWard would see it, e.g. by wrapping a "local({...})" around the code in question. Of course this would only make sense, if the end result of your computation is a more managable dataset, that you can then assign/return to globalenv(). (Generally objects with many rows are fine (e.g. data.frame's), only large lists / environments are a problem).
So, indeed, I guess for now the only viable solution is to use plain R for such tasks. I'll keep the problem in mind, and I have some basic ideas on how to fix this, but as mentionend, this is going to take some time.