understand that opening the stack invisibly first will greatly
improve performance.
Monte, thanks again for your test. Most illuminating.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http
No problem Richard, fun tracking this stuff down. After your last
email, I now understand the exact reason for the slowdown.
I now plan to switch all my long name references over to use the
control ID. Everything in the doc says using the ID should be a safe
way to uniquely identify a
On 11/12/10 11:44 AM, Peter Haworth wrote:
There's a little trepidation on my part about
that because I occasionally see posts that suggest that maybe there's
issues with the uniqueness of IDs but hopefully I won;t run into them!
They won't change unless you change them yourself, and the only
/Standalone performance issue, it's nothing to do with the
code.
I my last email I mentioned how I have a custom property holding the long
names of all the controls on a card that need to have data loaded into them
from my database. On closer inspection, the long name includes the name
I think I have found the cause of the performance problems I have
been experiencing. I had been referring to objects by their long name
in various places in the offending code. I started changing the code
to refer to the same objects by their short ID and each line of code I
changed
, 2010, at 10:03 AM, Peter Haworth wrote:
I think I have found the cause of the performance problems I have been
experiencing. I had been referring to objects by their long name in various
places in the offending code. I started changing the code to refer to the
same objects
Peter Haworth wrote:
I think I have found the cause of the performance problems I have
been experiencing. I had been referring to objects by their long name
in various places in the offending code. I started changing the code
to refer to the same objects by their short ID and each line
Yeah, and Peter's issue was that with standalones, the problem is many orders
of magnitude worse.
Bob
On Nov 11, 2010, at 11:04 AM, Richard Gaskin wrote:
So it seems that the overhead of resolving absolute object references (long
form) is much higher than what the engine can do when
. :)
Yeah, and Peter's issue was that with standalones, the problem is
many orders of magnitude worse.
Understood, but as I noted I was unable to measure any difference
between standalone and IDE performance greater than about 0.0008 ms per
call.
At that rate it would take many hundreds of thousands
these results I can see that there's a benefit to hard-wire
the type in script where practical.
Thanks for bringing this up. Learn sumpin' new every day. :)
Finding the problem is good of course but does anyone know why there
are no performance issues referring to an object by it's long name
Peter Haworth wrote:
Here's a small example section of code which I've changed to use the
ID where it used to use the long name. The variables are:
myIDholds the short ID of the control
pselection a parameter passed into the command
put the milliseconds into mymilliseconds
See answers below.
Pete Haworth
What's interesting there is that the control is only being
referenced three times: once to write the debug string, a second
time to check the customKeys, and a third time to obtain the prop
values.
Given that it's just three object references and most
Figured out the IDE/Standalone performance issue, it's nothing to do
with the code.
I my last email I mentioned how I have a custom property holding the
long names of all the controls on a card that need to have data loaded
into them from my database. On closer inspection, the long name
Peter Haworth wrote:
Figured out the IDE/Standalone performance issue, it's nothing to do
with the code.
I my last email I mentioned how I have a custom property holding the
long names of all the controls on a card that need to have data loaded
into them from my database. On closer inspection
Unless you're explicitly purging the stacks, any access to a property of a
stack file will load it into memory. The first access will take a hit only
if the stack isn't already in memory, but subsequent accesses should be about
as fast whether referring to just the stack name or the stack
Yes, that's what I'm seeing. With the references to my .rev filepath
in the control names, the card I'm using to test was taking around 35
seconds to open. I went through and manually removed the references
to the filepath (that's the only thing I changed I swear!) and built
the
Monte Goulding wrote:
Unless you're explicitly purging the stacks, any access to
a property of a stack file will load it into memory. The
first access will take a hit only if the stack isn't already
in memory, but subsequent accesses should be about as fast
whether referring to just the
that there would be such a performance difference.
Maybe it was something to do with resolving the filename? I'm not sure, I just
know it was slower.
Cheers
Monte___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe
I guess my experience suggests strongly that the stack doesn't stay in memory
but I can't prove it. Is there something I can write to my debug log that would
help prove this one way or the other?
Richard Gaskin ambassa...@fourthworld.com wrote:
Monte Goulding wrote:
Unless you're explicitly
Monte Goulding wrote:
I never said it wasn't loaded into memory. I know it is and it
didn't make sense to me at the time that there would be such a
performance difference. Maybe it was something to do with
resolving the filename? I'm not sure, I just know it was slower.
There's probably
There's probably some nuance I'm missing - here's a quick test which first
uses the fileName of a stack to access a property, then the next run it opens
the stack and gets the property by referring to the stack's short name (FWIW,
I had saved the stack previously with its destroyStack set
to anticipate, but very good to know.
So Peter has a solution, and I learned two new things today about
performance.
A good day...
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http
, Monte! Thanks for running that test.
So the difference is in addressing controls *within* a stack, but
not with the stack itself. Hard to anticipate, but very good to know.
So Peter has a solution, and I learned two new things today about
performance.
A good day
Spent the last day or so trying to get some data to track this problem
down by inserting code to write details of the time taken for various
chunks of code to execute into a text file so I could see what was
going on. I narrowed it down to a command that loads the text
property of an
I think you are on to something there Peter. This may be something for the bug
reports. Is there a test stack with the debug written into it that you could
post so we can try it on our end?
Bob
On Nov 9, 2010, at 10:13 AM, Peter Haworth wrote:
Spent the last day or so trying to get some
...@lists.runrev.com
wrote:
Date: Tue, 9 Nov 2010 10:26:39 -0800
From: Bob Sneidar b...@twft.com
Subject: Re: More on IDE vs Standalone Performance issues
To: How to use Revolution use-revolution@lists.runrev.com
Message-ID: 6f5b0f5e-e1a5-4c49-93af-bca8c73fc...@twft.com
Content-Type: text/plain
4.5 of performance issues! I
rebuilt my application using Rev Studio 4.0 using the same code base and the
performance issues are still there in the standalone.
So the issue now is that the problem doesn't occur in the IDE, only in the
standalone and I don't see any code that distinguishes
Thanks for all the input. I've pretty much ruled out SQLite as the
cause of the problem because I'm using the same database in the IDE
and the standalone so unless the standalone is using a different
SQLite library than the IDE, there shouldn't be any difference in
performance between
I just built my first standalone with LiveCode 4.5 (on OSX) and I'm
seeing painfully slow performance compared to the same application
built with 4.0.
I'm using an SQLite database to populate all the data on the cards in
the app, not sure if there's some problem with the SQLite side
Peter Haworth wrote:
I just built my first standalone with LiveCode 4.5 (on OSX) and I'm
seeing painfully slow performance compared to the same application
built with 4.0.
I'm using an SQLite database to populate all the data on the cards in
the app, not sure if there's some problem
On 11/6/10 8:30 AM, Peter Haworth wrote:
I just built my first standalone with LiveCode 4.5 (on OSX) and I'm
seeing painfully slow performance compared to the same application
built with 4.0.
I'm using an SQLite database to populate all the data on the cards in
the app, not sure if there's
Peter,
what happens when you use dbsqlite.bundle from the 4.0 release with the 4.5
engine?
Cheers,
Malte___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
On Sat, Nov 6, 2010 at 2:30 PM, Peter Haworth p...@mollysrevenge.comwrote:
I just built my first standalone with LiveCode 4.5 (on OSX) and I'm seeing
painfully slow performance compared to the same application built with 4.0.
I'm using an SQLite database to populate all the data on the cards
I guess I was too hasty in accusing LiveCode 4.5 of performance
issues! I rebuilt my application using Rev Studio 4.0 using the same
code base and the performance issues are still there in the standalone.
So the issue now is that the problem doesn't occur in the IDE, only
Thanks Mark. I am having the client give it a try and will let you know
how it goes.
David Beck
Rotunda Software
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
Hello,
I have had two clients report serious performance problems with a
LiveCode standalone application on Windows 7, 32-bit machines. Dialogs
and windows take several minutes to open, when usually they take only
seconds. The same standalone (with the same data) works fine on other
David-
Monday, October 4, 2010, 10:18:03 AM, you wrote:
Has anybody else experiences this issue or have any ideas about what
could be the cause?
Try upgrading the Win7 video drivers (!)
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-revolution
On 10/4/10 12:18 PM, David Beck wrote:
Hello,
I have had two clients report serious performance problems with a
LiveCode standalone application on Windows 7, 32-bit machines. Dialogs
and windows take several minutes to open, when usually they take only
seconds. The same standalone
On 10/4/10 12:39 PM, Mark Wieder wrote:
David-
Monday, October 4, 2010, 10:18:03 AM, you wrote:
Has anybody else experiences this issue or have any ideas about what
could be the cause?
Try upgrading the Win7 video drivers (!)
Wow, who woulda thought? Video driver issues cause file dialog
Jacque-
Monday, October 4, 2010, 2:27:08 PM, you wrote:
Wow, who woulda thought? Video driver issues cause file dialog problems?
I believe you, but I can't imagine why that would be. Any idea?
Absolutely none. Just passing on what I've been told.
--
-Mark Wieder
mwie...@ahsoftware.net
On 10/4/10 6:57 PM, Mark Wieder wrote:
Jacque-
Monday, October 4, 2010, 2:27:08 PM, you wrote:
Wow, who woulda thought? Video driver issues cause file dialog problems?
I believe you, but I can't imagine why that would be. Any idea?
Absolutely none. Just passing on what I've been told.
I
A more efficient way of doing this would be to group the buttons and
set the backcolor of each button to empty, then just
set the backcolor of group myBtnGroup to 89,149,218
and all the objects in the group will inherit the backcolor of the
group (as long as they don't have an individual
Hello,
For my actual project I need (and I search) the better performances when my
scripts are running...
I read in Scripter's Scrapbook :
- Put names in quotes. They are faster to compile since they are not checked
as variables first, and you cannot unintentionally confuse them with a variable
Hi René,
Quoted strings can't be interpreted as variables by the engine (as
long as quoted strings aren't numbers used as names for objects). For
me, this is the main reason to always put strings in quotes (besides
the fact that strings with spaces in them will cause errors if there
are
Thank you Mark,
In my project I use lot of do command...
For you, is that (the number of flux (flows) is 5) :
put add 1 to vgCompteurFlux vpNuméroduFlux into vxA ; do vxA
faster or slower than :
switch vpNuméroduFlux
case 1 ; add 1 to vgCompteurFlux1 ; break
case 2 ; add 1 to vgCompteurFlux2
René,
Case will definitely be faster. A good alternative would be:
add 1 to vgCompteurFlux[vpNumeroduFlux]
I wouldn't use special characters such as é in variable names. I very
rarely have to make such choices, because I have a different syle of
programming.
--
Best regards,
Mark
On 06/20/2010 01:11 PM, Mark Schonewille wrote:
Hi René,
Quoted strings can't be interpreted as variables by the engine (as
long as quoted strings aren't numbers used as names for objects). For
me, this is the main reason to always put strings in quotes (besides
the fact that strings with
In this case I would use an array
or custom properties. Much faster by far.
--variable array
add one to vgCpuFlux[ vpNumFlux ]
--custom property ( a trickier technique, but more powerful )
get the vgCpuFlux[ vpNumFlux ] of this stack +1
set the vgCpuFlux[ vpNumFlux ] of this stack to
Thank you Mark,
Perhaps some milliseconds won... :-)
I understand about using (or not using) é, but all work well...
without accents it is not possible to write french words...
Do you think that can have consequences about performance ?
René
Le 20 juin 2010 à 13:07, Mark Schonewille a écrit
Thank you very much Jim !
Le 20 juin 2010 à 13:18, Jim Ault a écrit :
In this case I would use an array
or custom properties. Much faster by far.
--variable array
add one to vgCpuFlux[ vpNumFlux ]
--custom property ( a trickier technique, but more powerful )
get the vgCpuFlux[
I have also this case : no variable but object (button) name :
repeat with i = 1 to 21
put set the backColor of btn quote btnHarmo i quote to
89,149,218 into vxA ; do vxA
end repeat
is array solution possible ?
or it is necessary to do :
set the backColor of btn btnHarmo1 to
René,
repeat with i = 1 to 21
put btnHarmo i into myBtn
set the backColor of btn myBtn to 89,149,218
end repeat
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
Subscribe
Le 20 juin 2010 à 15:07, René Micout a écrit :
I have also this case : no variable but object (button) name :
repeat with i = 1 to 21
put set the backColor of btn quote btnHarmo i quote to
89,149,218 into vxA ; do vxA
end repeat
meme effet que ton code, sans le DO, donc
YES !
That seems obvious when one sees !
It is sometimes necessary to step aside to see what is right before us.
Hartelijk dank
Le 20 juin 2010 à 15:15, Mark Schonewille a écrit :
René,
repeat with i = 1 to 21
put btnHarmo i into myBtn
set the backColor of btn myBtn to 89,149,218
end
Même réponse que Mark donc même merci (mais en français !)
Bon souvenir de Paris
René
Le 20 juin 2010 à 15:19, Thierry a écrit :
Le 20 juin 2010 à 15:07, René Micout a écrit :
I have also this case : no variable but object (button) name :
repeat with i = 1 to 21
put set the
Thierry gave you the answer earlier today with a repeat loop.
The better solution would not use an array for this task.
On Jun 20, 2010, at 6:07 AM, René Micout wrote:
I have also this case : no variable but object (button) name :
repeat with i = 1 to 21
put set the backColor of btn
Hi René,
Here is also another way to accomplish a similar task when you are trying to
set the same property of many objects.
put name,address,city,state,country into tItems
repeat for each item I in tItems
set the textfont of field I to Verdana
set the fontsize of field I to 9
end repeat
About the same as running GraphicConverter.
On Sun, Mar 14, 2010 at 5:33 AM, Randall Reetz rand...@randallreetz.com wrote:
Ok, that is the hype. I have no reason to believe it isn't a good
translator. What I am asking is its impact on the performance of the OS
Ok, that is the hype. I have no reason to believe it isn't a good translator.
What I am asking is its impact on the performance of the OS?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe
Hi Randall,
Contrary to the older Classic environment, which allows for running
Mac OS 9, Rosetta doesn't affect the performance of the operating
system as a whole. It only slows down PowerPC applications, if you'd
compare them with native Intel versions of the same applications.
--
Best
Is there one? Just having it installed?
Randall
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
My understanding is that Rosetta is just a PPC (and OS 9) emulator... and a
very good one, too. Having it installed (and no OS 9 apps running) is no
more a performance hit than having Parallels or VMware Fusion installed and
not running.
Jeff M.
On Fri, Mar 12, 2010 at 12:57 PM, Randall Lee
Does anyone know the answer to this system performance hit (running rosetta)?
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http
Mac. There’s no emulation. No
second-class status. It looks and feels just like it did before. On a Mac,
you’d expect nothing less.
Bons souvenirs de Paris
René
Le 13 mars 2010 à 07:43, Randall Reetz a écrit :
Does anyone know the answer to this system performance hit (running rosetta
and unlocks the screen significantly increases
screen refresh performance compared to executing the send AFTER unlocking
the screen. I suppose this might be due to Rev being able to cue the next
send before updating the screen but I would have expected send to operate
independently of the screen update
send in... loop.
I just discovered an odd (but perhaps expected?) relationship between the
send command and locking the screen. It seems that placing send in...
within a handler that locks and unlocks the screen significantly increases
screen refresh performance compared to executing the send
Scott Rossi wrote:
What strategies do you employ to get the
best responsiveness out of your apps during tight repeat loops?
You could try putting in a wait 1 millisecond with messages somewhere
in the loop. It yields time to the interface so the controls can respond.
--
Jacqueline Landman
Dear Viktoras, thanks a lot for the suggestions. Yes VB is compiled
(although in a sort of p-code) and it isexpected to be faster than any
scripting language. I did't try to do what you have suggested because I am
not
mastering other languages but VB6 and FORTRAN. I am also convinced that
trying
Hi Bernard, you are certianly right about RB. Indeed I am following their
developmentduring the years. I am pretty sure that the same code will be
probably faster in RB than in VB6
but I have yet to decide to buy their compiler.
As you said, what is attractive in RevMedia is its free character and
I just tried it in Rev Studio. Changed 'N' to 50 under mouseup, it
took a shade over 30 seconds to diagonalise, I'm using a 4 year old
AMD 64 3200+.
I'll leave the optimising to others for now..
2009/8/27 Piero Ugliengo piero.uglie...@gmail.com:
I am completely new to Revolution. I have
I am completely new to Revolution. I have downloaded the RevMedia alpha
version and played a bit with it. I was impressed by how fast I was able to
port a little VB6 code to RevMedia. This code diagonalizes a symmetric
matrix using the Jacobi algorithm. I checked against the VB6 code and I got
I saw this over on the forum (the diagonalisation takes about twenty
seconds on my MacBookPro with rev enterprise), and two things occur
to me.
'Arrays' in revolution are actually hash tables, so are very nice for
random access to elements, but will not be as efficient for
sequential
Dear Mark, thanks a lot for the advise. Things like 1.0 istead of 1 were
just my ignorance of the language.On the other hand I thought that the
syntax a[i][j] instead of the more readable a[i,j] was imposed by the
language.
Cheers
Piero
2009/8/27 Mark Smith li...@futilism.com
I saw this over on
Hi Piero,
declaring local/global variables in functions and handlers should
slightly add to speed. Populating arrays in advance with zeros so that
array size won't change inside loops might also be of some value.
However, please correct me if I am wrong, VB6 is compiled while
Revolution is
Viktoras,
Maybe the wording in the IDE (and maybe the docs) is misleading.
After all, the button in the script editor says 'compile', not just
'save' or 'check syntax'. It might very well be that it is compiled
into some form of p-code that doesn't mean that it needs to be
re-compiled each time
messages have a shorter
path to travel to them.
If you're not currently participating in the beta testing for v3.5 just
sit tight a while longer, it's coming. And when it's here, the new
behaviors feature will not only change the way you script, but in some
cases may boost performance along
CPU cycles (not
querying the database all the time) and bandwidth (not transfering
webpages that are cached and did not change).
Andre
On Sat, May 31, 2008 at 1:29 AM, David Bovill [EMAIL PROTECTED] wrote:
I'd like to speed up performance of a Rev based CGI by caching the results
on the server
I'd like to speed up performance of a Rev based CGI by caching the results
on the server - however I want to retain the CGI based dynamic behaviour.
From reading around it looks like this is possible, and I think this could
be a generally useful hack for Rev based CGI's. AFAIK this is a fairly
the Scrolling Field and compared it to the Table Field, using
20,844 lines - big difference, where the Scrolling Field won in it's
performance of no degradation of stack resize.
But I've never used this object before, because I lose the formatting of
columnar presentation.
If I use this object
Hi Mark,
use scrolling field object with vgrid and hgrid set to true (table to
false), so you will get it formatted correctly without all the overheads
of the table object. I always use this when I need table and it for me
handles a few thousand records without any slowing downs.
One more
Hi,
Hi Sarah,
That sounds promising, especially reading prior threads on the
same custom
property concept.
The data was there already. I actually MOVED it to custom properties
rather than duplicating the data, so the overhead was no worse than it
had been and quite acceptable. The
columns from the SQL table. The
record length for the Table Field then is 200.
I also tried the Scrolling Field and compared it to the Table Field, using
20,844 lines - big difference, where the Scrolling Field won in it's
performance of no degradation of stack resize.
But I've never used
Hi All,
I have a question about large data sets (thousands of lines) in a table
object and the slowing down of the UI performance, especially on resizing
the stack.
My application interfaces to an MS SQL 2000 database via ODBC. No problem
there.
The SQL table I have has over half a million
, at 19:04, mfstuart wrote:
Hi All,
I have a question about large data sets (thousands of lines) in a
table
object and the slowing down of the UI performance, especially on
resizing
the stack.
My application interfaces to an MS SQL 2000 database via ODBC. No
problem
there.
The SQL table I
--- mfstuart [EMAIL PROTECTED] wrote:
Hi All,
I have a question about large data sets (thousands
of lines) in a table
object and the slowing down of the UI performance,
especially on resizing
the stack.
My application interfaces to an MS SQL 2000 database
via ODBC. No problem
Jan Schenkel wrote:
Now when large record sets are returned from a
search, the UI (user
interface) slows down, especially when resizing the
stack to see more
records in the table object. When resizing with no
records, the UI is
performs normally with fast resizing.
...
The problem is
' chunked download approach, allows us
to squeeze every drop of performance out of our
favourite development tool...
Jan Schenkel.
Quartam Reports PDF Library for Revolution
http://www.quartam.com
=
As we grow older, we grow both wiser and more foolish at the same time. (La
Rochefoucauld
I haven't tried storing data in a custom property as yet, but wouldn't that
render the same lack of performance behavior, where putting the data into a
stack of the UI?
Mark Stuart
masmit wrote:
Mark, you might store the data from the database in a custom property
of the table field
On Fri, Feb 22, 2008 at 9:21 AM, mfstuart [EMAIL PROTECTED] wrote:
I haven't tried storing data in a custom property as yet, but wouldn't that
render the same lack of performance behavior, where putting the data into a
stack of the UI?
No, because the engine doesn't have to think about how
Hi Richard,
My day job is a software engineer, using another software development tool -
eDeveloper.
The product we build (CRM) is for enterprise sized companies, working on
large amounts of SQL data.
eDeveloper does not produce this UI lack of performance during runtime. This
is how I noticed
sets (thousands
of lines) in a table
object and the slowing down of the UI performance,
especially on resizing
the stack.
My application interfaces to an MS SQL 2000 database
via ODBC. No problem
there.
The SQL table I have has over half a million records
in it, and this grows
all the time
mfstuart wrote:
My day job is a software engineer, using another software development tool -
eDeveloper.
The product we build (CRM) is for enterprise sized companies, working on
large amounts of SQL data.
eDeveloper does not produce this UI lack of performance during runtime. This
is how I
Gaskin wrote:
mfstuart wrote:
My day job is a software engineer, using another software development
tool -
eDeveloper.
The product we build (CRM) is for enterprise sized companies, working on
large amounts of SQL data.
eDeveloper does not produce this UI lack of performance during runtime
mfstuart wrote:
I did as you suggested and copied 8 columns of data (20,844 lines) into this
new stack.
Just a table object on the card - no scripts (except your 'on resizeStack'
in the stack), no other objects.
resize result: same slow behavior :(
Any other thoughts on that?
How much data is
Mark,
Are you using a table object, or a regular scrolling field with the
hGrid and vGrid properties turned on? The former is an emulated
control which may slow down significantly, while the latter should be
significantly faster.
In the past, I've managed to put data on the order of 20
PROTECTED] wrote:
I haven't tried storing data in a custom property as yet, but wouldn't
that
render the same lack of performance behavior, where putting the data
into a
stack of the UI?
No, because the engine doesn't have to think about how to display your
data, it's just storing whatever you
, mfstuart [EMAIL PROTECTED] wrote:
I haven't tried storing data in a custom property as yet, but wouldn't
that
render the same lack of performance behavior, where putting the data
into a
stack of the UI?
No, because the engine doesn't have to think about how to display your
)
On the stack I'm only using 8 of the 13 columns from the SQL table. The
record length for the Table Field then is 200.
I also tried the Scrolling Field and compared it to the Table Field, using
20,844 lines - big difference, where the Scrolling Field won in it's
performance of no degradation of stack resize
Table appearance in a scrolling field can also be accomplished just
using tabs.
Check out the table pulldown on the object inspector
uncheck table object
check hgrid and or vgrid
grid lines color can be subtle
If I use this object, is there a way to set it to columnar appearance?
And
conservative on windows at least
regards
Martin
On 11/05/07, Bill Marriott [EMAIL PROTECTED] wrote:
Klaus,
does anyone have some experience/hints with/for the performance of RevXML
with big XML files? [...] we want to avoid using a real database engine.
Your biggest issue with big anything is memory
1 - 100 of 176 matches
Mail list logo
