| பதிவின் பக்கங்கள்: [1 2] > | Storing the dictionaries on a RAM disk இழை இடுபவர்: CafeTran Trainer
|
|---|
Hi fellow Transit users,
Currently I'm experimenting with a RAM disk to store some of my TermStar dictionaries.
In OS X I've created a RAM disk using Make RAM disk:
http://www.macupdate.com/app/mac/36418/make-ram-disk
Then I start Parallels 7 and WinXP. I create a new MDB and ODBC link to my RAM disk.
Term adding is blaz... See more Hi fellow Transit users,
Currently I'm experimenting with a RAM disk to store some of my TermStar dictionaries.
In OS X I've created a RAM disk using Make RAM disk:
http://www.macupdate.com/app/mac/36418/make-ram-disk
Then I start Parallels 7 and WinXP. I create a new MDB and ODBC link to my RAM disk.
Term adding is blazing fast, even faster than on my SSD  .
Of course I'll have to back-up the MDB from the RAM before shutting of the iMac.
Nice thing of this solution is that I can reboot my WinXP without losing my newly added terms.
Another positive side-effect is that the amount of memory occupied for the MDB is taken from the host OS, thus leaving more RAM available in my WinXP 32 bit. Not that the amount of available RAM has ever been an issue here ....
Question: Can I store an SQL database in RAM too?
Cheers,
Hans ▲ Collapse
| | | |
What sort of SSD do you use? Good SSDs easily hit 400-500MB/s seq reads now, so all the extra futzing around with a RAMdisk is probably not worth it anymore.
I can't imagine you'll save more than a couple hundreths of a second on a normal dictionary lookup/term add.
BTW don't RAMdisks work just like any disk? I.e. you can put anything on there, I'd assume.
| | | | | Background Dictionary in RAM? | Feb 28, 2012 |
Hans Lenting wrote:
Question: Can I store an SQL database in RAM too?
Perhaps I should even move back to Access databases for my (large) Background Dictionary. Since the only instability Transit is experiencing, is caused by the SQL driver:
http://dl.dropbox.com/u/509643/Clients/Screen%20Shot%202012-02-28%20at%2011.41.58%20AM.png
BTW: What is a good value for the max. number of entries in an Access MDB? 100,000 term pairs?
| | | | Neil Coffey 
யுனைடட் கிங்டம்
Local time: 14:54
ஃபிரன்ச் - ஆங்கிலம்
+ ...
| CAT must be really poorly written then | Feb 28, 2012 |
Hans Lenting wrote:
Term adding is blazing fast, even faster than on my SSD .
If you notice much of a difference, then your CAT tool must be really poorly written. If stored on hard disk, constantly-accessed data should be properly cached in memory so that you shouldn't notice much difference if the file is moved to a RAM disk. This is Programming 101. I would shout at the authors about this.
Hans Lenting wrote:
Question: Can I store an SQL database in RAM too?
Well, a SQL database is just a bunch of files at the end of the day, so in principle, yes, provided they fit and your DB engine/software can be persuaded to put the files there. It's not what the DB would normally be expecting (the point of a database is that the files are kind of always there when you expect them to be, and not subject to randomly disappearing if your computer crashes...)
But in any case, if the database and database engine are well written then in principle there shouldn't be terribly much advantage, and it could even be detrimental. Again, your DB *should* automatically be caching frequently-used data in memory automatically and writing it to disk in a background thread. And, depending on which engine you're using, DB files are typically large, possibly larger than the amount of RAM in your machine. Some DB's, notably MySQL, actually allow the developer to store certain "temporary" tables in RAM anyway, so if the program is well designed, tables that are good candidates to be put in a RAM disk will already be stored in RAM by the DB anyway.
| | |
|
|
|
| I cannot complain ;) | Feb 28, 2012 |
Neil Coffey wrote:
If you notice much of a difference, then your CAT tool must be really poorly written
I cannot complain. Transit is well-written. If there weren't this SQL issue ...
Thanks for your reply. I'll check it out.
BR,
Hans
| | | |
FarkasAndras wrote:
What sort of SSD do you use?
It is the standard SSD that Apple builds in an iMac 27".
| | | |
Hans Lenting wrote:
FarkasAndras wrote:
What sort of SSD do you use?
It is the standard SSD that Apple builds in an iMac 27".
IIRC they use a mix of Samsung and Toshiba, always a step or two behind what's fastest. (They prefer reliability to bleeding edge performance, and they like to save money on parts, too). Obviously, the speed will depend heavily on when the thing was made. The speed of SSDs roughly doubled each year in the last 3 or 4 years - i.e. if you care about performance, an SSD upgrade might be worth looking into.
| | | | | Term base getting slower after adding new terms | Mar 8, 2012 |
Hi Neil,
Thanks again for your extensive reply. Please excuse my late reaction.
Hans Lenting wrote:
Term adding is blazing fast, even faster than on my SSD .
After having added several thousands of terms on the fly I must say that adding new terms is getting slower. One might say 'What is the big point if you'll have to wait a couple of seconds after adding a new term pair!?'. But when you're into the habit of storing term pairs in nearly every segment you translate, these seconds do add up ..
If you notice much of a difference, then your CAT tool must be really poorly written. If stored on hard disk, constantly-accessed data should be properly cached in memory so that you shouldn't notice much difference if the file is moved to a RAM disk. This is Programming 101. I would shout at the authors about this.
IMO Transit NXT isn't poorly written. It is very stable and offers lots of useful and advanced features (that other CAT tools don't offer). I must admit that I'm driving the term base to the limits here, with more than 600,000 term pairs. (Although, on the other hand, this quantity of term pairs doesn't cause problems in some other CAT tools, e.g. Déjà Vu, MemoQ, CafeTran -- the latter is a very nice Java tool, BTW)
Luckily STAR is reading here so I don't need to shout.
Well, a SQL database is just a bunch of files at the end of the day, so in principle, yes, provided they fit and your DB engine/software can be persuaded to put the files there. It's not what the DB would normally be expecting (the point of a database is that the files are kind of always there when you expect them to be, and not subject to randomly disappearing if your computer crashes...)
For the time being I've decided not to go that road (of storing the SQL DB in RAM).
Currently I'm facing two kinds of problems. Perhaps you can give me a word of advice on how to tackle them:
1. The (small) Access DB (either on SSD, HD or in RAM) that I use to add my new term pairs to, is getting slower (that is: adding new terms is taking more time) after having added about 8,000-10,000 new terms. Compacting the DB doesn't change this.
2. The (large) SQL DB that I use to store the Background Dictionary sometimes (2 or 3 times on some days, not at all on many days) gives the error reported here. After this Transit becomes instable and I have to reboot WinXP (32 bit). The error mostly occurs after rapid adding of several new terms in a short time -- which is strange, because the terms aren't added to the SQL DB (but to the Access DB).
These problems have always been there. On different computers, even with fresh installations. So I think it is a fundamental weakness of Transit (XV and NXT). I've had a lot of correspondence with STAR about this topic but they cannot offer a solution. So I'll have to come up with a solution myself ...
I must say that I don't understand why this issue isn't solved. Transit is such a good product that IMO is way more advanced that its competitors. If only this terminology issue wouldn't exist ... (I'd be completely happy with it).
Thanks for your advice!
BR,
Hans
| | |
|
|
|
DZiW (X)
யூக்ரேன்
ஆங்கிலம் - ருஷ்ஷியன்
+ ...
is always faster and better than slow or set to compatibility HDD's (I hate when a brand-new 1TB SATA2 is configured as Multi-Word 2 or even PIO mode) or expensive limited-transaction SSD's (blast that short-living stuff).
Actually, I think that you have already worked with virtual ramdisks or someone has given you a good piece of advice. The only drawback is power loss (use UPS) and RAM available (not a problem nowadays for 4+ GB models).
Working with my old notebook I... See more is always faster and better than slow or set to compatibility HDD's (I hate when a brand-new 1TB SATA2 is configured as Multi-Word 2 or even PIO mode) or expensive limited-transaction SSD's (blast that short-living stuff).
Actually, I think that you have already worked with virtual ramdisks or someone has given you a good piece of advice. The only drawback is power loss (use UPS) and RAM available (not a problem nowadays for 4+ GB models).
Working with my old notebook I used to have a CMD (aka BAT) file which automatically mounted a RAM disk and copied my TM folder there, so I could work with it at a wink--not a bad trade-off option for an oldie core-duo with 4GB and HDD 400GB @5400rpm, I must admit
Frankly speaking I don't have a huge TM (a little over 60 MB) so I don't use RAMdisk on my desktops, but it's a good save for notebooks, at least from my view and exp. ▲ Collapse
| | | | Michael Beijer
யுனைடட் கிங்டம்
Local time: 14:54
உறுப்பினர்
டச் - ஆங்கிலம்
+ ...
| (slightly OT, but...) a quick question about paging files + SSDs | Mar 17, 2012 |
After reading this thread I started wondering about paging files again. Mine is currently set to 'No paging file', but I was wondering what everyone here has theirs set to. The reason I'm asking this is that I've been having some problems with slow-downs in memoQ, which I think might be due to the size of the VERY BIG TMs I have been using in my projects lately.
specs: Windows 7 64bit, 120GB Intel SSD, 16GB of RAM, i7 CPU.
| | | |
Michael Beijer wrote:
After reading this thread I started wondering about paging files again. Mine is currently set to 'No paging file', but I was wondering what everyone here has theirs set to. The reason I'm asking this is that I've been having some problems with slow-downs in memoQ, which I think might be due to the size of the VERY BIG TMs I have been using in my projects lately.
specs: Windows 7 64bit, 120GB Intel SSD, 16GB of RAM, i7 CPU.
If I were in your shoes, I would switch it back on, but limit its size to something like 1GB or 2GB. I don't think you will see any performance improvement, because you are probably never even close to using all your physical RAM, so the pagefile will mostly sit idle. The reason why I'd switch it on is that some people say that the lack of a page file can cause problems (some programs may not even run) - better safe than sorry. I don't think Windows is so dumb as to dump stuff from RAM to the pagefile unnecessarily, so you won't see any performance loss.
(The reasony why I'd recommend limiting the size: By default, Windows would set up a 16+ gig pagefile for you, which would obviously be huge pain when you only have 120GB of space. The more an SSD is filled up, the faster it wears, so a 16GB pagefile is definitely not a good use of drive space.)
I'm in a somewhat similar boat with my 120GB SSD, but only 4GB RAM. Currently I'm letting Windows manage the pagefile, so it's close to 4GB. Maybe I could get away with shrinking it down to 2GB...?
[Edited at 2012-03-17 21:12 GMT]
| | | | Michael Beijer
யுனைடட் கிங்டம்
Local time: 14:54
உறுப்பினர்
டச் - ஆங்கிலம்
+ ...
| @FarkasAndras | Mar 18, 2012 |
Thanks for the info!
I decided to switch it back on and let Windows manage it, but as you said: that left me with a 16GB paging file, which is not exactly ideal given the limited space on my SSD. So I have another question:
I actually have 2 drives in my computer, the SSD I mentioned, but also a fast 1TB HDD storage drive. Should I maybe put the paging file on my HDD storage drive (D:), and none on my SSD (C:), or should I perhaps put say a 1-2 GB paging file on my D:, ... See more Thanks for the info!
I decided to switch it back on and let Windows manage it, but as you said: that left me with a 16GB paging file, which is not exactly ideal given the limited space on my SSD. So I have another question:
I actually have 2 drives in my computer, the SSD I mentioned, but also a fast 1TB HDD storage drive. Should I maybe put the paging file on my HDD storage drive (D:), and none on my SSD (C:), or should I perhaps put say a 1-2 GB paging file on my D:, and a very small one on my SSD?
Incidentally, after I (re)enabled the paging file, I seemed to notice that memoQ was once again able to deal with large TMs without the slow-downs I mentioned in my previous post. I say 'seemed', because this could of course also have been down to wishful thinking.
PS: sorry for hijacking your topic Hans! ▲ Collapse
| | |
|
|
|
I'd not put a pagefile on the HDD. SSDs work much better for paging due to faster access times. I'm sure you could set aside 2GB for this...? I really don't think there could possibly be a need for 16 GB of swap, so there's no need to set it up in two chunks. You can move media files from he SSD to the HDD to free up space, they don't benefit from a faster drive anyway.
| | | | | short-lived SSDs | Mar 18, 2012 |
DZiW wrote:
is always faster and better than slow or set to compatibility HDD's (I hate when a brand-new 1TB SATA2 is configured as Multi-Word 2 or even PIO mode) or expensive limited-transaction SSD's (blast that short-living stuff).
SSDs are not short-lived. They have a limited number of write-erase cycles for each cell (5000-10000 or so), but if you have a modern OS and a modern drive, you won't bump into that limit in practical use. If you were to wipe your drive and completely fill it up with data every single day, a good drive would last 20+ years. Due to write amplification and imperfect wear leveling, real use can wear it out faster than the theoretical example of a daily full write/erase cycle, but it's still not an issue to worry about.
http://www.anandtech.com/show/2829/6
| | | | DZiW (X)
யூக்ரேன்
ஆங்கிலம் - ருஷ்ஷியன்
+ ...
| vista, w7 and on | Mar 18, 2012 |
For what it's worth, FarkasAndras, I don't find some of your statements reasonable enough.
First, using the fastest drive just for temporary file(s) is... not the best opt, especially--as you've already mentioned it--some 16GB RAM should make it rarely accessed, if ever.
Second, while modern SATA-3 speed is 600MB/s even plain (unbuffered non-registered non-ECC) low-end DDR3 speed is from 6.4GB/s whereas high-end speed is over 17GB/s. How slow is your beloved SSD in-bet... See more For what it's worth, FarkasAndras, I don't find some of your statements reasonable enough.
First, using the fastest drive just for temporary file(s) is... not the best opt, especially--as you've already mentioned it--some 16GB RAM should make it rarely accessed, if ever.
Second, while modern SATA-3 speed is 600MB/s even plain (unbuffered non-registered non-ECC) low-end DDR3 speed is from 6.4GB/s whereas high-end speed is over 17GB/s. How slow is your beloved SSD in-between, let alone its price?
Third, journal-intensive systems like Vista, w7 and on (perhaps) keep constantly over/rewriting logs and other service meta/data what wears SSD much faster than you might see from ads. I've already mentioned that my brand-new Vista managed to kill a precious (in both senses) SSD less than two years, whereas downgraded similar system worked years until upgrade under XP without any problems. Not an absolutely proven fact, but it tells a tale, because I don't believe ads.
Therefore, I would try a single fixed size (e.g. from 2GB to 2GB) swapfile on a non-system disk/partition and tried MemoQ or something to make sure. Then I would try memdisk as the database storage to compare.
Indeed, only server machines are able to have a huge amount of RAM installed (I've seen a home server motherboard with 4 CPU slots and 32 RAM slots with 'just' 192GB onboard), so it's not an ordinary PC any longer, but fancy is that if one is working with big databases then he probably needs a server. Another funny thing is that using PAE even MS Server 2003 x32 could easily handle 64/128GB.
Shortly, I personally see no use of misusing SSD's and prefer RAM than teeny-weeny gadgets like SSD--inspite of the ads they are still low-end rejection hi-tek for a rather hi-end price. Also I worked under quite big projects with MemoQ and had no speed issues, so I wouldn't exclude some software conflicts. ▲ Collapse
| | | | | பதிவின் பக்கங்கள்: [1 2] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Storing the dictionaries on a RAM disk | Trados Studio 2022 Freelance | The leading translation software used by over 270,000 translators.
Designed with your feedback in mind, Trados Studio 2022 delivers an unrivalled, powerful desktop
and cloud solution, empowering you to work in the most efficient and cost-effective way.
More info » |
| | Anycount & Translation Office 3000 | Translation Office 3000
Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
