You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by David Jordan <Da...@sas.com> on 2011/09/11 18:29:58 UTC
some surprising performance results
I am getting some performance numbers that don't make sense based on my understanding of how Jena and SDB work. It was my understanding that nothing is cached in memory, that each API call will result in queries performed against the database. But I am getting very different results, suggesting that on the very first call, a significant amount of processing takes place to produce the results, that is then used for subsequent calls.
I’ll try to explain in detail what I have. There is an ICD9 ontology, it is strictly a hierarchy of 11874 classes, each class has a singleton, the hierarchy is around 5 levels deep. Since this is a read-only set of data, I created an OntModel with the appropriate level of reasoning, output this and then read it into another model. Below is a list of the number of nodes for that ICD9 model, in both forms, to give you an idea of how large it is.
mysql> select lex, count(*) from Nodes, Quads where g = hash group by lex;
+---------------------------------------------------------+----------+
| lex | count(*) |
+---------------------------------------------------------+----------+
| http://purl.bioontology.org/ontology/HOM_ICD9/ | 73420 |
| http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ | 262024 |
| http://www.sas.com/hls/hoa/patient/ | 1282 |
+---------------------------------------------------------+----------+
Though I am reading in the patient ontology, I am not yet using it, that will be my next test.
For the benchmark application, I read in a file that contains the following descriptions of diseases, defined via a set of ICD9 codes. I add the HOM_ICD9_inferred and patient ontologies using addSubModel().
@prefix : <http://www.sas.com/hls/ ex/> .
@prefix HOM_ICD9: <http://purl.bioontology.org/ontology/HOM_ICD9/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
:Disease rdf:type owl:Class ;
rdfs:label "Disease"^^xsd:string .
:Colon_Cancer rdf:type owl:Class ;
rdfs:subClassOf :Disease ;
rdfs:label "Colon Cancer"^^xsd:string .
:Anal_Cancer rdf:type owl:Class ;
rdfs:subClassOf :Disease ;
rdfs:label "Anal Cancer"^^xsd:string .
:Lung_Cancer rdf:type owl:Class ;
rdfs:subClassOf :Disease ;
rdfs:label "Lung Cancer"^^xsd:string .
:Breast_Cancer rdf:type owl:Class ;
rdfs:subClassOf :Disease ;
rdfs:label "Breast Cancer"^^xsd:string .
:Prostate_Cancer rdf:type owl:Class ;
rdfs:subClassOf :Disease ;
rdfs:label "Prostate Cancer"^^xsd:string .
:Breast_Cancer a owl:Class ;
owl:unionOf (
HOM_ICD9:HOM_ICD_10558 # V10.3
HOM_ICD9:HOM_ICD_1292 # 174
HOM_ICD9:HOM_ICD_1297 # 174.4
HOM_ICD9:HOM_ICD_1300 # 174.8
HOM_ICD9:HOM_ICD_1294 # 174.1
HOM_ICD9:HOM_ICD_1295 # 174.2
HOM_ICD9:HOM_ICD_1299 # 174.6
HOM_ICD9:HOM_ICD_1758 # 233
HOM_ICD9:HOM_ICD_1296 # 174.3
HOM_ICD9:HOM_ICD_1298 # 174.5
HOM_ICD9:HOM_ICD_1304 # 175.9
HOM_ICD9:HOM_ICD_1301 # 174.9
HOM_ICD9:HOM_ICD_1302 # 175
) .
:Lung_Cancer a owl:Class ;
owl:unionOf (
HOM_ICD9:HOM_ICD_1231 # 162.9
HOM_ICD9:HOM_ICD_1744 # 231.2
HOM_ICD9:HOM_ICD_10551 # V10.11
HOM_ICD9:HOM_ICD_1228 # 162.4
HOM_ICD9:HOM_ICD_1229 # 162.5
HOM_ICD9:HOM_ICD_1227 # 162.3
HOM_ICD9:HOM_ICD_1230 # 162.8
HOM_ICD9:HOM_ICD_1544 # 209.21
HOM_ICD9:HOM_ICD_1226 # 162.2
) .
:Colon_Cancer a owl:Class ;
owl:unionOf (
HOM_ICD9:HOM_ICD_10546 # V10.05
HOM_ICD9:HOM_ICD_1170 # 153.6
HOM_ICD9:HOM_ICD_1166 # 153.2
HOM_ICD9:HOM_ICD_1169 # 153.5
HOM_ICD9:HOM_ICD_1163 # 153
HOM_ICD9:HOM_ICD_1165 # 153.1
HOM_ICD9:HOM_ICD_1734 # 230.3
HOM_ICD9:HOM_ICD_1173 # 153.9
HOM_ICD9:HOM_ICD_1168 # 153.4
HOM_ICD9:HOM_ICD_1540 # 209.16
HOM_ICD9:HOM_ICD_1539 # 209.15
HOM_ICD9:HOM_ICD_1538 # 209.14
HOM_ICD9:HOM_ICD_1537 # 209.13
HOM_ICD9:HOM_ICD_1172 # 153.8
HOM_ICD9:HOM_ICD_1536 # 209.12
HOM_ICD9:HOM_ICD_1535 # 209.11
HOM_ICD9:HOM_ICD_1171 # 153.7
HOM_ICD9:HOM_ICD_1533 # 209.1
HOM_ICD9:HOM_ICD_1167 # 153.3
HOM_ICD9:HOM_ICD_1202 # 159
) .
:Prostate_Cancer a owl:Class ;
owl:unionOf (
HOM_ICD9:HOM_ICD_10566 # V10.46
HOM_ICD9:HOM_ICD_1767 # 233.4
HOM_ICD9:HOM_ICD_1343 # 185
) .
:Anal_Cancer a owl:Class ;
owl:unionOf (
HOM_ICD9:HOM_ICD_1179 # 154.8
HOM_ICD9:HOM_ICD_10547 # V10.06
HOM_ICD9:HOM_ICD_1178 # 154.3
HOM_ICD9:HOM_ICD_8412 # 796.76
HOM_ICD9:HOM_ICD_8410 # 796.74
HOM_ICD9:HOM_ICD_8409 # 796.73
HOM_ICD9:HOM_ICD_1177 # 154.2
HOM_ICD9:HOM_ICD_8408 # 796.72
HOM_ICD9:HOM_ICD_8407 # 796.71
HOM_ICD9:HOM_ICD_8405 # 796.7
HOM_ICD9:HOM_ICD_1737 # 230.6
HOM_ICD9:HOM_ICD_1736 # 230.5
HOM_ICD9:HOM_ICD_1174 # 154
HOM_ICD9:HOM_ICD_1735 # 230.4
HOM_ICD9:HOM_ICD_1541 # 209.17
) .
Below are the results from running my program on a laptop. Once I do this on our server, I expect to get better numbers, but the general pattern of time differences will likely be the same. As you can see, the very first access of the Prostate_Cancer class and its instances to 4081 seconds, for just 3 classes involved. Yet subsequent calls to the other disease classes took substantially less time. Can this all be attributed to the time it takes the database to cache things, or is something going on in Jena that explains this???
I’ll be running this on our Linux server and will also try TDB for the ICD9 ontology to see if how much difference it makes. But it would be really nice to hear if there is a Jena or SDB specific explanation for these results.
Performance will be an important consideration for this application. I want to be sure I am doing things in a way that gets to best possible performance when using Jena.
Loading http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ took 0.359 seconds
Loading http://www.sas.com/hls/patient/ took 0.0 seconds
http://www.sas.com/hls/ex/Prostate_Cancer
3 instances found.
Access took 4080.932 seconds
http://www.sas.com/hls/ex/Breast_Cancer
28 instances found.
Access took 3.313 seconds
http://www.sas.com/hls/ex/Lung_Cancer
9 instances found.
Access took 1.062 seconds
http://www.sas.com/hls/ex/Anal_Cancer
17 instances found.
Access took 1.656 seconds
http://www.sas.com/hls/ex/Colon_Cancer
25 instances found.
Access took 2.641 seconds
http://www.sas.com/hls/ex/Disease
81 instances found.
Access took 4.891 seconds
David Jordan
Software Developer
SAS Institute Inc.
Health & Life Sciences, Research & Development
Bldg R ▪ Office 4467
600 Research Drive ▪ Cary, NC 27513
Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
www.sas.com<http://www.sas.com>
SAS® … THE POWER TO KNOW®
RE: some surprising performance results
Posted by David Jordan <Da...@sas.com>.
Thanks Andy, this was my suspicion. I ruled out the database as the cause by doing a first run to get all the data I wanted, stop the application, then immediately re-ran it. Results were the same, so the database was not the cause. I did not know whether the inferences were calculated in a dynamic, lazy evaluation fashion, or done in bulk up front. This test and your explanation confirms this happens on the first call.
I do plan on trying TDB for the ICD9 data, but cannot use it for all the data because of the need for concurrent updating for some of the other data. I'll be anxious to see how much TDB improves the results.
-----Original Message-----
From: Andy Seaborne [mailto:andy.seaborne@epimorphics.com]
Sent: Monday, September 12, 2011 4:20 AM
To: jena-users@incubator.apache.org
Subject: Re: some surprising performance results
On 11/09/11 17:29, David Jordan wrote:
>
>
> I am getting some performance numbers that don't make sense based on
my understanding of how Jena and SDB work. It was my understanding that nothing is cached in memory, that each API call will result in queries performed against the database. But I am getting very different results, suggesting that on the very first call, a significant amount of processing takes place to produce the results, that is then used for subsequent calls.
It is true that SDB does not do client-side caching (the DB server is cachign liek crazy as all SQL systems do). But if you put an inference model over a SDB model, then the inference layer is caching. A lot of work can happen on first use, then the inferences are already calculated.
You can confimr this by looking at the DB log - if I underatand your setup, operations are the first shoudl arely if all cause any SQL traffic.
TDB is going to be faster to back an ontology model with inference. A lot of quite fine grained data requests are done and SDB incurs JDBC overhead on each one.
Andy
>
> I’ll try to explain in detail what I have. There is an ICD9 ontology,
it is strictly a hierarchy of 11874 classes, each class has a singleton, the hierarchy is around 5 levels deep. Since this is a read-only set of data, I created an OntModel with the appropriate level of reasoning, output this and then read it into another model. Below is a list of the number of nodes for that ICD9 model, in both forms, to give you an idea of how large it is.
> mysql> select lex, count(*) from Nodes, Quads where g = hash group by
> mysql> lex;
> +---------------------------------------------------------+----------+
> | lex | count(*) |
> +---------------------------------------------------------+----------+
> | http://purl.bioontology.org/ontology/HOM_ICD9/ | 73420 |
> | http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ | 262024 |
> | http://www.sas.com/hls/hoa/patient/ | 1282 |
> +---------------------------------------------------------+----------+
>
> Though I am reading in the patient ontology, I am not yet using it, that will be my next test.
>
> For the benchmark application, I read in a file that contains the following descriptions of diseases, defined via a set of ICD9 codes. I add the HOM_ICD9_inferred and patient ontologies using addSubModel().
>
> @prefix :<http://www.sas.com/hls/ ex/> .
> @prefix HOM_ICD9:<http://purl.bioontology.org/ontology/HOM_ICD9/> .
> @prefix xsd:<http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> .
> @prefix owl:<http://www.w3.org/2002/07/owl#> .
>
> :Disease rdf:type owl:Class ;
> rdfs:label "Disease"^^xsd:string .
>
> :Colon_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Colon Cancer"^^xsd:string .
>
> :Anal_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Anal Cancer"^^xsd:string .
>
> :Lung_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Lung Cancer"^^xsd:string .
>
> :Breast_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Breast Cancer"^^xsd:string .
>
> :Prostate_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Prostate Cancer"^^xsd:string .
>
> :Breast_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10558 # V10.3
> HOM_ICD9:HOM_ICD_1292 # 174
> HOM_ICD9:HOM_ICD_1297 # 174.4
> HOM_ICD9:HOM_ICD_1300 # 174.8
> HOM_ICD9:HOM_ICD_1294 # 174.1
> HOM_ICD9:HOM_ICD_1295 # 174.2
> HOM_ICD9:HOM_ICD_1299 # 174.6
> HOM_ICD9:HOM_ICD_1758 # 233
> HOM_ICD9:HOM_ICD_1296 # 174.3
> HOM_ICD9:HOM_ICD_1298 # 174.5
> HOM_ICD9:HOM_ICD_1304 # 175.9
> HOM_ICD9:HOM_ICD_1301 # 174.9
> HOM_ICD9:HOM_ICD_1302 # 175
> ) .
>
> :Lung_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_1231 # 162.9
> HOM_ICD9:HOM_ICD_1744 # 231.2
> HOM_ICD9:HOM_ICD_10551 # V10.11
> HOM_ICD9:HOM_ICD_1228 # 162.4
> HOM_ICD9:HOM_ICD_1229 # 162.5
> HOM_ICD9:HOM_ICD_1227 # 162.3
> HOM_ICD9:HOM_ICD_1230 # 162.8
> HOM_ICD9:HOM_ICD_1544 # 209.21
> HOM_ICD9:HOM_ICD_1226 # 162.2
> ) .
>
> :Colon_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10546 # V10.05
> HOM_ICD9:HOM_ICD_1170 # 153.6
> HOM_ICD9:HOM_ICD_1166 # 153.2
> HOM_ICD9:HOM_ICD_1169 # 153.5
> HOM_ICD9:HOM_ICD_1163 # 153
> HOM_ICD9:HOM_ICD_1165 # 153.1
> HOM_ICD9:HOM_ICD_1734 # 230.3
> HOM_ICD9:HOM_ICD_1173 # 153.9
> HOM_ICD9:HOM_ICD_1168 # 153.4
> HOM_ICD9:HOM_ICD_1540 # 209.16
> HOM_ICD9:HOM_ICD_1539 # 209.15
> HOM_ICD9:HOM_ICD_1538 # 209.14
> HOM_ICD9:HOM_ICD_1537 # 209.13
> HOM_ICD9:HOM_ICD_1172 # 153.8
> HOM_ICD9:HOM_ICD_1536 # 209.12
> HOM_ICD9:HOM_ICD_1535 # 209.11
> HOM_ICD9:HOM_ICD_1171 # 153.7
> HOM_ICD9:HOM_ICD_1533 # 209.1
> HOM_ICD9:HOM_ICD_1167 # 153.3
> HOM_ICD9:HOM_ICD_1202 # 159
> ) .
>
> :Prostate_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10566 # V10.46
> HOM_ICD9:HOM_ICD_1767 # 233.4
> HOM_ICD9:HOM_ICD_1343 # 185
> ) .
>
> :Anal_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_1179 # 154.8
> HOM_ICD9:HOM_ICD_10547 # V10.06
> HOM_ICD9:HOM_ICD_1178 # 154.3
> HOM_ICD9:HOM_ICD_8412 # 796.76
> HOM_ICD9:HOM_ICD_8410 # 796.74
> HOM_ICD9:HOM_ICD_8409 # 796.73
> HOM_ICD9:HOM_ICD_1177 # 154.2
> HOM_ICD9:HOM_ICD_8408 # 796.72
> HOM_ICD9:HOM_ICD_8407 # 796.71
> HOM_ICD9:HOM_ICD_8405 # 796.7
> HOM_ICD9:HOM_ICD_1737 # 230.6
> HOM_ICD9:HOM_ICD_1736 # 230.5
> HOM_ICD9:HOM_ICD_1174 # 154
> HOM_ICD9:HOM_ICD_1735 # 230.4
> HOM_ICD9:HOM_ICD_1541 # 209.17
> ) .
>
> Below are the results from running my program on a laptop. Once I do this on our server, I expect to get better numbers, but the general pattern of time differences will likely be the same. As you can see, the very first access of the Prostate_Cancer class and its instances to 4081 seconds, for just 3 classes involved. Yet subsequent calls to the other disease classes took substantially less time. Can this all be attributed to the time it takes the database to cache things, or is something going on in Jena that explains this???
>
> I’ll be running this on our Linux server and will also try TDB for the ICD9 ontology to see if how much difference it makes. But it would be really nice to hear if there is a Jena or SDB specific explanation for these results.
>
> Performance will be an important consideration for this application. I want to be sure I am doing things in a way that gets to best possible performance when using Jena.
>
>
>
> Loading http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ took
> 0.359 seconds Loading http://www.sas.com/hls/patient/ took 0.0 seconds
> http://www.sas.com/hls/ex/Prostate_Cancer
> 3 instances found.
> Access took 4080.932 seconds
>
> http://www.sas.com/hls/ex/Breast_Cancer
> 28 instances found.
> Access took 3.313 seconds
>
> http://www.sas.com/hls/ex/Lung_Cancer
> 9 instances found.
> Access took 1.062 seconds
>
> http://www.sas.com/hls/ex/Anal_Cancer
> 17 instances found.
> Access took 1.656 seconds
>
> http://www.sas.com/hls/ex/Colon_Cancer
> 25 instances found.
> Access took 2.641 seconds
>
> http://www.sas.com/hls/ex/Disease
> 81 instances found.
> Access took 4.891 seconds
>
>
> David Jordan
> Software Developer
> SAS Institute Inc.
> Health& Life Sciences, Research& Development Bldg R ▪ Office 4467
> 600 Research Drive ▪ Cary, NC 27513
> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
> www.sas.com<http://www.sas.com>
> SAS® … THE POWER TO KNOW®
>
>
>
Re: some surprising performance results
Posted by Andy Seaborne <an...@epimorphics.com>.
On 11/09/11 17:29, David Jordan wrote:
>
>
> I am getting some performance numbers that don't make sense based on
my understanding of how Jena and SDB work. It was my understanding that
nothing is cached in memory, that each API call will result in queries
performed against the database. But I am getting very different results,
suggesting that on the very first call, a significant amount of
processing takes place to produce the results, that is then used for
subsequent calls.
It is true that SDB does not do client-side caching (the DB server is
cachign liek crazy as all SQL systems do). But if you put an inference
model over a SDB model, then the inference layer is caching. A lot of
work can happen on first use, then the inferences are already calculated.
You can confimr this by looking at the DB log - if I underatand your
setup, operations are the first shoudl arely if all cause any SQL traffic.
TDB is going to be faster to back an ontology model with inference. A
lot of quite fine grained data requests are done and SDB incurs JDBC
overhead on each one.
Andy
>
> I’ll try to explain in detail what I have. There is an ICD9
> ontology,
it is strictly a hierarchy of 11874 classes, each class has a singleton,
the hierarchy is around 5 levels deep. Since this is a read-only set of
data, I created an OntModel with the appropriate level of reasoning,
output this and then read it into another model. Below is a list of the
number of nodes for that ICD9 model, in both forms, to give you an idea
of how large it is.
> mysql> select lex, count(*) from Nodes, Quads where g = hash group by lex;
> +---------------------------------------------------------+----------+
> | lex | count(*) |
> +---------------------------------------------------------+----------+
> | http://purl.bioontology.org/ontology/HOM_ICD9/ | 73420 |
> | http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ | 262024 |
> | http://www.sas.com/hls/hoa/patient/ | 1282 |
> +---------------------------------------------------------+----------+
>
> Though I am reading in the patient ontology, I am not yet using it, that will be my next test.
>
> For the benchmark application, I read in a file that contains the following descriptions of diseases, defined via a set of ICD9 codes. I add the HOM_ICD9_inferred and patient ontologies using addSubModel().
>
> @prefix :<http://www.sas.com/hls/ ex/> .
> @prefix HOM_ICD9:<http://purl.bioontology.org/ontology/HOM_ICD9/> .
> @prefix xsd:<http://www.w3.org/2001/XMLSchema#> .
> @prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> .
> @prefix owl:<http://www.w3.org/2002/07/owl#> .
>
> :Disease rdf:type owl:Class ;
> rdfs:label "Disease"^^xsd:string .
>
> :Colon_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Colon Cancer"^^xsd:string .
>
> :Anal_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Anal Cancer"^^xsd:string .
>
> :Lung_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Lung Cancer"^^xsd:string .
>
> :Breast_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Breast Cancer"^^xsd:string .
>
> :Prostate_Cancer rdf:type owl:Class ;
> rdfs:subClassOf :Disease ;
> rdfs:label "Prostate Cancer"^^xsd:string .
>
> :Breast_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10558 # V10.3
> HOM_ICD9:HOM_ICD_1292 # 174
> HOM_ICD9:HOM_ICD_1297 # 174.4
> HOM_ICD9:HOM_ICD_1300 # 174.8
> HOM_ICD9:HOM_ICD_1294 # 174.1
> HOM_ICD9:HOM_ICD_1295 # 174.2
> HOM_ICD9:HOM_ICD_1299 # 174.6
> HOM_ICD9:HOM_ICD_1758 # 233
> HOM_ICD9:HOM_ICD_1296 # 174.3
> HOM_ICD9:HOM_ICD_1298 # 174.5
> HOM_ICD9:HOM_ICD_1304 # 175.9
> HOM_ICD9:HOM_ICD_1301 # 174.9
> HOM_ICD9:HOM_ICD_1302 # 175
> ) .
>
> :Lung_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_1231 # 162.9
> HOM_ICD9:HOM_ICD_1744 # 231.2
> HOM_ICD9:HOM_ICD_10551 # V10.11
> HOM_ICD9:HOM_ICD_1228 # 162.4
> HOM_ICD9:HOM_ICD_1229 # 162.5
> HOM_ICD9:HOM_ICD_1227 # 162.3
> HOM_ICD9:HOM_ICD_1230 # 162.8
> HOM_ICD9:HOM_ICD_1544 # 209.21
> HOM_ICD9:HOM_ICD_1226 # 162.2
> ) .
>
> :Colon_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10546 # V10.05
> HOM_ICD9:HOM_ICD_1170 # 153.6
> HOM_ICD9:HOM_ICD_1166 # 153.2
> HOM_ICD9:HOM_ICD_1169 # 153.5
> HOM_ICD9:HOM_ICD_1163 # 153
> HOM_ICD9:HOM_ICD_1165 # 153.1
> HOM_ICD9:HOM_ICD_1734 # 230.3
> HOM_ICD9:HOM_ICD_1173 # 153.9
> HOM_ICD9:HOM_ICD_1168 # 153.4
> HOM_ICD9:HOM_ICD_1540 # 209.16
> HOM_ICD9:HOM_ICD_1539 # 209.15
> HOM_ICD9:HOM_ICD_1538 # 209.14
> HOM_ICD9:HOM_ICD_1537 # 209.13
> HOM_ICD9:HOM_ICD_1172 # 153.8
> HOM_ICD9:HOM_ICD_1536 # 209.12
> HOM_ICD9:HOM_ICD_1535 # 209.11
> HOM_ICD9:HOM_ICD_1171 # 153.7
> HOM_ICD9:HOM_ICD_1533 # 209.1
> HOM_ICD9:HOM_ICD_1167 # 153.3
> HOM_ICD9:HOM_ICD_1202 # 159
> ) .
>
> :Prostate_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_10566 # V10.46
> HOM_ICD9:HOM_ICD_1767 # 233.4
> HOM_ICD9:HOM_ICD_1343 # 185
> ) .
>
> :Anal_Cancer a owl:Class ;
> owl:unionOf (
> HOM_ICD9:HOM_ICD_1179 # 154.8
> HOM_ICD9:HOM_ICD_10547 # V10.06
> HOM_ICD9:HOM_ICD_1178 # 154.3
> HOM_ICD9:HOM_ICD_8412 # 796.76
> HOM_ICD9:HOM_ICD_8410 # 796.74
> HOM_ICD9:HOM_ICD_8409 # 796.73
> HOM_ICD9:HOM_ICD_1177 # 154.2
> HOM_ICD9:HOM_ICD_8408 # 796.72
> HOM_ICD9:HOM_ICD_8407 # 796.71
> HOM_ICD9:HOM_ICD_8405 # 796.7
> HOM_ICD9:HOM_ICD_1737 # 230.6
> HOM_ICD9:HOM_ICD_1736 # 230.5
> HOM_ICD9:HOM_ICD_1174 # 154
> HOM_ICD9:HOM_ICD_1735 # 230.4
> HOM_ICD9:HOM_ICD_1541 # 209.17
> ) .
>
> Below are the results from running my program on a laptop. Once I do this on our server, I expect to get better numbers, but the general pattern of time differences will likely be the same. As you can see, the very first access of the Prostate_Cancer class and its instances to 4081 seconds, for just 3 classes involved. Yet subsequent calls to the other disease classes took substantially less time. Can this all be attributed to the time it takes the database to cache things, or is something going on in Jena that explains this???
>
> I’ll be running this on our Linux server and will also try TDB for the ICD9 ontology to see if how much difference it makes. But it would be really nice to hear if there is a Jena or SDB specific explanation for these results.
>
> Performance will be an important consideration for this application. I want to be sure I am doing things in a way that gets to best possible performance when using Jena.
>
>
>
> Loading http://purl.bioontology.org/ontology/HOM_ICD9_inferred/ took 0.359 seconds
> Loading http://www.sas.com/hls/patient/ took 0.0 seconds
> http://www.sas.com/hls/ex/Prostate_Cancer
> 3 instances found.
> Access took 4080.932 seconds
>
> http://www.sas.com/hls/ex/Breast_Cancer
> 28 instances found.
> Access took 3.313 seconds
>
> http://www.sas.com/hls/ex/Lung_Cancer
> 9 instances found.
> Access took 1.062 seconds
>
> http://www.sas.com/hls/ex/Anal_Cancer
> 17 instances found.
> Access took 1.656 seconds
>
> http://www.sas.com/hls/ex/Colon_Cancer
> 25 instances found.
> Access took 2.641 seconds
>
> http://www.sas.com/hls/ex/Disease
> 81 instances found.
> Access took 4.891 seconds
>
>
> David Jordan
> Software Developer
> SAS Institute Inc.
> Health& Life Sciences, Research& Development
> Bldg R ▪ Office 4467
> 600 Research Drive ▪ Cary, NC 27513
> Tel: 919 531 1233 ▪ david.jordan@sas.com<ma...@sas.com>
> www.sas.com<http://www.sas.com>
> SAS® … THE POWER TO KNOW®
>
>
>